Why is TUI used in stores? - tui

In many big stores/rental/service companys the system they are using for managing customers and looking up products is based on a Text User Interface (TUI). Are there any reason why they choose TUI over GUI or is it just old systems?

From my experience, it's just old systems. If the old system still works, many companies don't see why they should spend a lot of money only to get the TUI replaced by a GUI.

Now is 2017 and TUI is still widely used in stores, gas-stations, etc...
I personally find TUI (specially TurboVision based apps) much more eye-appealing then too rich GUI apps. Also, by looking into how users use TUI apps (mostly spend time with numerical keyboards without need for mouse) I get the feeling they are faster in using TUI.

Related

Standalone Desktop Application

I have been tasked with the creation of a desktop application within some very rigid constrains. The first version of the application was quite small, only intended for some specific tasks, but it seems like the application was quite liked, so I've been asked to improve it a lot.
The initial app I created was made as a hta with heavy doses of javascript and jquery, using a XML to store information (through MSXML2.3.0), but the increased amount of data makes me think it won't be able to keep up with the requirements, so I wanted to remake the application on a more solid base. Of course, I'd rather keep the interface more or less consistent with what I've already shown, and I'd prefer not having to rewrite all the code.
The restrictions are as follows:
-Desktop application. I cannot develop a web application, as not a single target computer has a solid internet connection.
-No need of installation (copying and pasting the folder should work, and should keep all the data consistent).
-Should be relatively multi plataform. The only information I have about the target machines is that all of them have a windows XP OS or newer, a MS Office 2003 suite or newer, and some kind of PDF reader.
-Should be able to embed and show different file types, such as diferent image formats, pdfs, and office documents. That said, for office documents, as long as I can link to the document and open it by instanciating a common MS Word/Excel/wathever app, it should be good enough, although interoperativity with the suite would be great.
I've been searching through the net, and I've found some interesting options, but I'm not sure about them.
On one side, I think XML won't be able to keep up, although I suppose I could make it work if I distribute the data through several xml files. I've been reading about open source embedded databases, such as SQLite, and it looks like this could work.
On the other side, I feel like the hta basis I'm using isn't going to work that well if the application keeps growing. I've checked lots of alternatives, but all of them give me some problems.
Cappuccino or Chromeless looks like good ideas, but both of them require a certain degree of HTML5, which is something I can't be sure the machine's browser will support enough. Also, NativeHost for Cappuccino seems to work only on Mac OSX. Xul looks interesting, but unusable.
Another option I've found is porting the app to Qt, but I don't know how hard would be porting the app to Qts, and it looks like I can only use the ActiveX needed for the embedding of MS Office applications with a proprietary license. Although that's comparatively less important, but I'm sure in the future I'll want to include those features.
That's how I stand. Do you think keeping the hta + XML architecture (or any variation thereof) could still work? Do any of the alternatives I've mentioned be viable? Do you know any other alternative?

Windows phone 7 native code support

2 questions:
Can someone tell me if unmanaged c++ code will
be supported in future versions of Phone 7 OS for all developers?
What are MS reasons for not
supporting unmanaged c++ code?
This answer is purely speculative, but I feel that most others who have answered this question miss the point by a long shot. Let's for a moment assume that this is not a vindictive decision by Microsoft, but instead actually a very well thought out engineering decision that has absolutely nothing to do with content restrictions or otherwise. Those issues are just a bonus for MS
Microsoft is entering into the mobile market, this time for real it seems. Pretty soon there will be tens of millions of Nokia phone being shipped using Windows Phone and whatever they get on top of that will just be gravy. Windows Phone though still hasn't really found its home.
In the next year or two, phones, tablets and laptops will finally start converging into a single device. People will carry their phone in their pockets, but that phone will also be the CPU unit of their PC. That means that by simply sitting near a wireless HDMI monitor and connecting a keyboard and mouse via wireless USB (or bluetooth if we're all unlucky), the user will have their entire PC with them at all times. Tablets will become just a battery powered touch screen which interfaces to the PC in your pocket.
So, all software written for Windows Phone should be able to run unmodified on a PC, a tablet and/or a phone. This is because there's a huge chance that the PC you're running will be either x86 or ARM based running Windows 8. When the PC is in your pocket, the user interface you'll see will be the Windows Phone GUI. When you're hooked up to a monitor, you'll see the ribbon interface. But the underlying OS will most likely be Windows 8, not the Windows CE that is currently used.
Based on all this, the only way Microsoft can insure that developers who invest in producing apps for the Windows Mobile market will not be screwed and that users of Windows Mobile devices won't be shorted when the newer platform comes around is to ensure there is a standard system for running apps on all these processors.
Even now, writing for Honeycomb is a nightmare since if you develop native code, you have to support both ARM and x86 and there's no real support mechanism for it. The only solution is to develop, package and ship two versions. Writing apps for iDevices are a little easier since there's no overlap. x86 on desktop, ARM on device. If you have to use native code on device, ARM is all you need. Even then, there is fat binary support on both device and desktop, so this won't be a problem except when optimizing.
In the end, the decision by Microsoft to stick strictly to .NET is probably a good one. Once they have a gazillion Nokia phones on the market and things have settled a bit, native code could be a real possibility.
These answers are for the application development perspective. OEMs can write native code today, as that's how they create drivers, but that's not open or available to most developers and therefore of no use to most.
For #1 Microsoft has made no announcements, so only Microsoft knows the answer and they're not saying.
For #2 it's all about code security and overall platfrom stability It's very tough to sandbox native code and they don't want your app being able to affect other apps or the platform itself. The general idea is that you should be using Silverlight or XNA for application development, so that's what they expose.
Windows phones will go nowhere with native support. Games and other more intensive apps are driving sales. Android was forced to blow the lid off of its NDK to support the games industry. As far as supporting multiple processors, etc., those of us doing this kind of work have been doing it for a long time, so its no problem. Already handling Intel and ARM without a problems with our systems.
EDIT, finally: for WP7 unmanaged code won't ever be supported, but in Windows Phone 8 - yes it will! They've just announced it. Native apps, C/C++, iOS/Android portability and code sharing, DirectX. You'll need Visual Studio 2012 and Windows 8 for WP8 development, though. Looks like VS2010 is not getting the requisite WinRT SDK.
The nongame UI, however, will still be XAML-based. Win32 API will not be supported. They're pushing a model with managed UI layer and a native middleware beneath it.
SDK will be available later this summer.
For the sake of posterity, here's the pre-06/20/2012 answer:
Microsoft probably can.
To ensure platform closeness, as a means for attaining stability and UI consistency. To enforce app isolation. Also, to make jailbreaking/rooting harder.
EDIT: if you want a native SDK on WP7, like I do, please go sign this petition and/or that petition. Thank you!
EDIT: see this.
EDIT: also this. Still not official, but this rumor moves the timeframe for native app support even closer - to the upcoming Tango release.
I believe MS will support native development like C/C++. Really. Seriously.
Because, for end users, one of the killer app is game. And Most of game codes are based on C/C++. JS or C# based codes are exist, but meaningless from industrial perspective. Consider big players in game field like Unreal or EA. They made huge investment on C/C++ codebase. They won't give it up. In other words, MS has no power to force them to spend money for .NET. Even Xbox360 development offers C/C++ development. Because of that.
And leading platforms like iOS/Android all supports native development. WP can't bear up the situation without any game from big players. MS really wants 3rd path games, and offering native code is the only way to get them.
Of course, this can be applied to other apps which are not game, but games are biggest one. When C#/XNA just came out, there's no library. People had to make everything themselves. Now there're a little more, but still meaningless for professional games.
If MS won't offer native environment, just don't go there. MS wants to make developers to use managed .NET code, but .NET has too many limitations can be solved with only unmanaged code.
The only question is just when will MS support native development.

Do you use VIM/Emacs/Terminals to develop C/C++? What kind of projects is this practical for?

For those who are using vim/emacs/terminals,etc (ie, not an IDE proper) what sort of projects are you working on? Are they big? Production? Are these the tools you use at work? Or mostly for smaller things...or big things broken into small things? Sorry...enough questions.
I ask because I'm studying computer science right now, and am super excited about it. I had an internship programming J2ME for a government agency recently and it was Netbeans and eclipse all the way. So I've only had a few "minor-league" years in the business.
In short, what is practical for the CL type tools, versus an IDE such as 'beans and VS. I've got a lot to learn, and the CL tools will probably teach me, versus shielding me like an full on IDE might.
What sort of projects are you working on?
All kind... vim is my main "IDE" anywhere
Are they big?
Yes... My FOSS project CppCMS written almost 100% in vim
Production?
Yes, most of production code (Not FOSS) I write today I use vim.
Are these the tools you use at work?
Yes.
I would explain severak simple things:
vim provides almost all tools IDE does, highlighting, spellcheck, autocomplition, working with multiple buffers, build, context "jumps" (decl, def) and much more
It is extreamly portable, I work with it on Windows, Linux, OpenVMS, Solaris, FreeBSD.
It is very light in comparison to bloated IDE.
There is only one thing I do use IDE today: debugging hard bugs.
Emacs/Vim can be used for any sized projects.
Generally, you won't get to choose the environment, the job you find will have one already picked out for you (unless it's non-Java programming in Unix, in which case use what you want).
I wouldn't sweat the choice, just learn to use which ever editor/IDE is available to its utmost extent.
I use (and have used) Emacs for personal projects, and in two different companies on software projects exceeding 10M lines of production code each.
I use emacs. I would recommend emacs. I have used emacs since before it was emacs: TECO, TV, and the e macro package on the Decsystem-20.
I can use vim if I need to but what you learn is largely what is at hand and you get into.
Yes, learn one or both. And I would say, if the IDE fits, wear it too.
I use vim for everything, I hate IDEs, they're too bloated for me.
I haven't used it for any massive projects (because I haven't written any massive projects), but if I were going to, I would still use vim.
When learning I new language, I believe it's best to not use IDEs at all, and to learn the "proper" way of doing it (like for c++, learning the command line switches and using makefiles).
Twenty years ago all my programming was done in plain text editors, mostly emacs, but technology has improved over the years.
I still do use plain text editors to write code occasionally, but only when it is inconvenient to install an IDE on the machine where I'm writing code. For example, a few times I've stopped by a client site without my laptop and wanted to write a quick program.
This is also an issue with certain embedded systems, where you may want to update the code interactively through a RS232 or USB based command line interface.
Most modern IDEs provide enough acceleration to the code editing process that I will install one whenever I expect to use the computer for development for more than two or three hours.
I use vim for everything from small one-off scripts to 1000+ line production code. It is so versatile that working in any other environment seems constricting. If I'm part of a project that necessitates a standard environment (IDE) then I'll do as much coding as I can in vim and then import into the ide.
I believe everyone should be able to operate effectively in a command-line environment. You can't always be sure that anything except the basic tools will be available on the target machines, you can't be sure that you'll have enough system to pull up a full IDE, and you might actually find the system you're building is too complicated for an IDE.
I've built systems that have consisted of multiple interoperating clients and servers distributed across multiple physical machines. In these efforts, I have used command line tools almost exclusively in the server side. I will use DDD when I can, but I also know the underlying gdb. If the clients are Windows, I'll use the Visual Studio IDE, but if they're UNIX, I'll go with the command line.
Figure out how to work effectively using minimal tools. You'll be a better developer and you'll actually appreciate the integrated tools more, if they're done better.
BTW, I put Emacs in the IDE class. I've got a friend who comes in and fires it up first thing and doesn't leave the environment all day. It's more than an IDE, in fact, since he does mail, surfing, etc. in the thing, or so he tells me.
For large projects with 100+ files, using an IDE is very important. But there are lots of small small things which you need to keep doing all the time while working on even large projects. Firing up the IDE for all of these may not be worthwhile. Having a good command on a powerful editor like Vim or Emacs is something I would consider as an essential skill for any programmer. But an appropriate IDE should also be used to accelerate regular development work as per project needs.
Hmm... Well, look at it this way:
I open code in emacs. I edit it. I use code completion (and I've even played with intellisense emacs)... When I'm ready to compile, I hit CTRL+F7... A key I've bound... It builds in a small popup window... If there are any errors, I can jump to them in the code by hitting f8 (another bound key)... Once it's all building, I hit f5... (this runs a little program I wrote that parses the Makefile and determines the path the executable)... This starts the debugger in a small popup window... I can click on code lines to set break points... etc... I debug... I can "next" through the code with F10... I can "step" through the code with F11 (more key bindings)... When it's all done I hit Shift-F7 to package (.rpm) the project.
So, do I have an IDE? Or am I just using a plain text editor?
1. Yes. 2. Any kind of project.
There is no limit to the size of a system that can be developed in Vim/Emacs/Unix, in fact, there are fewer limits than there are in IDE's. Let's look at a few things I use...
SYSTEM LINES OF CODE
Linux kernel 10,000,000
NetBSD 4,000,000
Ruby 200,000
Those are pretty big systems.
I don't believe any of them were developed with IDE software.
I tend to agree that for learning it is a good idea to understand the basics: the fact that you edit the code, you compile it with a compiler, link it with a linker, debug it with a debugger.
It makes it easier to grasp the concepts. And it makes easier to move from platform to platform.
So, learn vi, make, gdb, some version control system (git, svn).
But for production I would say that getting familiar with the "standard IDE" of the environment is a must (Visual Studio for Windows, XCode for Mac OS, Eclipse for Java, etc.)
No mater what other say, mastering an IDE will increase your productivity.
If you used vi/emacs for 10 years and try Eclipse or Visual Studio for few days, you will say that they are bloated and don't offer anything in exchange. That's BS. The more open minded you are, the better you will be.
I use Emacs to develop commercial software with size of several millions LoC, and massive use of templates, etc. I use CEDET + gnu global as auxiliary packages + yasnippet, etc.
well...I have to say that I'm a vimmer. Using a IDE, I don't to care so many things like when you use editor like vim/emacs. But when you do a bit more, you will find the IDE you use is more hindering than helping in your program developping process. alas...if you insist in using vim/emacs as your editor, you will encounter "a deep learning curve", you will waste so many time even to acchieve so trivial a function in your editor,you will be desperate when you are busy catching up with your timetable if you just pick them up......you have to settle down and start leaning and also playing with editors and a couple of days, you will find you've already achieve more than you can ever expect!
My standard IDE is a flock of xterms running some mix of vim editors, man page documentation, debuggers, log tails, and command lines to execute things, plus an instance of Firefox for pulling up additional docs or (where applicable) testing web-based code. This is what I use for all projects these days, regardless of size, whether personal or professional.
Pretty much the only time I've seen real benefit to using an IDE has been when I've been working on platform-native GUI apps, where they make it so much easier to build forms and wire up their controls. But I haven't done that sort of work in over a decade - the last one I did was in Deplhi, back when Borland still owned it; I think version 4 had just come out, although it might have been 3.
Emacs is a great tool (so is Vim) for programming, and I use them to develop my code for physics research. As added benefit (for me) Emacs handles remote files nicely via Tramp, so that's big boom for me since I very often have to visit remote servers.
With that said, every time I need to write an application with a GUI and within a large framework (like c# with .NET or the android framework) I always find it hard to development with just emacs. The IDEs (Visual Studio, Eclipse) simply have everything including autocomplete and lookup with appropriate content from the framework, and debugging, even though code writing part is always unsatisfactory (I always end up installing some sort of emacs plugin for the IDE, which always fall short of Emacs proper!).
Sometimes it just takes too long to setup an environment in Emacs for those kinds of projects since that is not the default way envisioned by the designers, and having an environment that works out of box is so much easier than banging my head against the wall to find usually obscure information on how to compile/debug those app without using the designated IDE.
We could sum things up by saying that editors like emacs / vi implements some of the functionnalities of IDEs by using CL tools (or the libs behind the CL tools).
Your main issue in using an editor as an IDE would be :
configuring it to have exactly the functionnalities you are happy with in an IDE is not necessarily straigh-forward (I ask for sympathy from anyone who ever tried to configure CEDET ;) ), as opposed to working out-of-the-box with IDEs
the way such functionnalities work in editors is very tied to CL, so you need at least a vague understanding of the CL beforehand.
The advantages are the fact that CL tools are sometimes more ubiquitous than IDEs. Also mastering CL opens the door to scripting your build ("make a build in one command" as opposed to "make a build in one click"), which opens the door to automated nighly builds, continuous integration, etc... all of which are harder to setup if your understanding of the build stops at hitting F6 or whatever.

Best shortcut management tool for development machine?

As a developer I had a slew of shortcuts and applications used daily. Visual Studio 6, 2003, 2005, 2008, SQL Client tools, WinMerge, Notepad++, Synergy, VMware (and lots and lots of VMs, multiple browsers, and on top of all that about 20 shortcuts to important directories, servers, test environments etc...
The Vista start menu is a lifesaver for getting to many of them quickly. However there are plenty of daily tasks that still require a relatively large amount of work to access (open a folder, jump through a few sub-folders, find a specific file and fire it off.
What tools/applications/utilities do you find to be the most beneficial to providing organized and fast access to all of your most frequently visited tools?
What are some tools that can be embedded on the task bar of Windows that provide similar functionality to drawers in Linux or stacks in OS X? My current quick-launch bar (and other folders added to the task bar) eat up tons of real estate and insist on opening new explorer windows to display sub-directories, which suffices but is still slow and polutes my desktop.
...can't wait for tomorrow to get the Win 7 RC and its finally improved task bar
Launchy. I first heard about it from Scott Hanselman.
Not sure if this is what you're looking for, but I'm a big fan of SlickRun. It's basically a command launcher tool, but it's how I launch almost everything.
Check out Fences from Stardock. It's very clever, and lets you keep your desktop clean and organized, even with lots of shortcuts. Oh, and it's free.
I love Humanized Enso.
Their product is free now, although it is no longer developed by the original authors.
There is also a Google Code project that builds on a Enso prototype, which allows you to easily extend it using Python.
Short summary:
Allows you to teach shortcuts to the program
Has nice features like:
Integrated translation...
Integrated Google Maps...
Integrated dictionary
Integrated Google search
etc...
Developed by the same people that are now working on Mozilla Ubiquity
I'm pretty fond of SlickRun
I use HotKeyboard
I think Virtual Desktop Manager is a good solution if you are using XP. I dont know there is a simillar microsoft product for windows Vista or not.. :(
Quicksilver style launchers are quite common to accomplish this task.
You press a keyboard shortcut or click on an icon in the tray, that pops up a window where you can search for your programs, documents, shortcuts, bookmarks, etc.
Check out Launchy, its simple, clean and free.

Simple Frameworks for Displaying Bitmaps and Handling Button Presses

We have a set of applications that basically display a bunch of bitmaps and text, then allow user to press "buttons" (certain bitmaps) that cause actions to occur.
We currently have these implemented using DirectX and a bunch of code to place the bitmaps and handle the button-presses. But we'd like to have the following features:
portable to Linux
some sort of "editor" that would allow us to lay out screens without hard-coding locations of elements in code
animation
we need to be able to overlay video
not resource intensive (these terminals don't have a lot of memory or CPU)
we're currently using C++, so management would prefer that, but other languages would be considered
We'd prefer a free, open-source solution, but would be willing to buy something if it is not too expensive. (We have a couple dozen developers, and tens of thousands of terminals deployed.)
We don't like the common GUI toolkits or widgets. We want something that has more of the look of a game than of a dialog box.
Any suggestions for off-the-shelf stuff we could use?
Maybe the way to go is something like Clutter or Allegro. If you check in this article at ArsTechnica what they are using Clutter for, you might get an idea how to use it. I don't know for sure if it works on Windows, but I'm pretty sure it does, considering it only depends on libraries that are supported under Windows.
You could try wxWidgets (it has wxBitmapButton) or try to implement your own solution using SDL for all of the graphics.
"We don't like the common GUI toolkits or widgets. We want something that has more of the look of a game than of a dialog box."
You realize that Trolltech's QT has a style sheet language for widgets? Take a look at their white paper, specifically page 60
http://trolltech.com/pdf/qt43-whitepaper-us.pdf
Going over your other requirements:
portable to Linux
Yes. Also supports Windows, Mac, and embedded environments.
some sort of "editor" that would allow us to lay out screens without hard-coding locations of elements in code
Qt's Designer is a very nice tool. I use it all the time.
animation
Qt supports this.
we need to be able to overlay video
Qt supports this.
not resource intensive (these terminals don't have a lot of memory or CPU)
This might be the fly in the ointment. You could check out Qt's embedded option. I've never used that myself.
we're currently using C++, so management would prefer that, but other languages would be considered
Qt is for C++ and works with all major compilers.
We'd prefer a free, open-source solution, but would be willing to buy something if it is not too expensive. (We have a couple dozen developers, and tens of thousands of terminals deployed.)
Qt has both open-source and closed source options.