Slashdot Mirror
Developing Attractive non-GUI Apps for Unix?
Lysol asks: "Many years ago I wrote a POS (Point of Sale System) in a language (that's amazingly still around) called PowerBasic. One thing I really liked about it was the ability to do inline assembly and compile to machine code, which was a very big deal for DOS-based Basic code. For my POS app I used many text graphic libraries that gave me a poor-mans GUI for DOS. Now I'm going back to school and I need to brush up on my C, and that got me thinking about developing it in Linux. When I deployed this system it ran on old 386 machines. A lot of newer systems run on expensive hardware and it would be cool to provide a free GPL POS on Linux that can function as aterminal/text based solution. If you've ever used a cash register, sometimes GUI stuff with a mouse is not the best...especially for end users." One only has to look at FreshMeat to find examples of text UI libraries (and I'm sure that list isn't a complete one), but which ones have you used that you found enjoyable to develop in? How easy would it be to develop a text-mode application that has a UI that is just as capable as any GUI?
"I first want to deploy it using a terminal interface instead of a GUI interface for the simple reason that there will be times when it's better to run thin machines without installing X11, and it might be easier to implement rather than jumping right into GTK or some X11 widget toolkit. So does anyone know of any character based UI libraries that are available for C?"
I someone telling us what we need...
But seriously, we need a multiple-mode interface description system where we can design the interface in a standard format then utilize it from text-mode, graphical and possibly web-based interfaces.
I'm planning on working on some partial implementation of something like this at work, but I could use some suggestions.
Should such a thing use XML as the layout format? Seems like the current trendy thing to use.
With the web-based interface, are we stuck with Java for validating input? Normal forms seem too clunky for things like that.
Is the project too big in scope to reasonably accomplish? There are things you can do in text-mode that you just can't do from a browser (like assigning meaning to a single keystroke). Likewise, mouse clicks lose their charm when there is no mouse attached.
Any input would be helpful. - TH
As far as I know, it only makes sense to do that with terms- but I enjoyed it so much I thought it'd make a pretty nifty GUI. The term-only GUI :D
http://www.vex.net/parnassus/apyllo.py/808292924.
Yes, I know, you're a C programmer... but (a) this might be useful to someone, and (b) you should really consider using python, at least for your prototype -- it's much, much faster to develop with.
Hell no: the DNA Lounge is a No Microsoft Zone, and will stay that way. Because the Linux POS market is so barren, we ended up going with plain-old cash registers, no network, no OS to speak of: just buttons and LEDs. Perhaps we'll upgrade someday when something better comes along that isn't prohibitively expensive.
Just write the thing in Elisp. We already have mailreaders, mp3 players, Intercal development environments, and a web browser -- just glue the appropriate parts together and move on with life! Plus, if your users get too frustrated, just set some keybinds to locate `doctor' when they hit F1:
Dewey, what part of this looks like authorities should be involved?
Take your pick: GPL or BSD Licensed. :-)
The Doctor What (KF6VNC)
"Beware by whom you are called sane."
Potato chips are a by-yourself food.
Ncurses is really great.l
It's remarkably easy to use, lets you update
portions of the screen, gives you more direct
access to the keyboard, has been fixed to let
you use STL in your curses apps (hooray!)
There are a few tutorials out there... if you're just looking for a quick view of how ncurses looks, grab "nmix" (a simple ncurses based sound card mixer) from freshmeat... the source is nice and small and demonstrates how simple it is.
As for tutorials/books...
http://www.cscene.org/CS3/CS3-08.html
http://www.oreilly.com/catalog/curses/index.htm
http://dickey.his.com/ncurses/ncurses.faq.html
Those should help set you on your way.
Now if only someone would make an AAlib Xserver.
...but add my voice to the chorus cheering for curses. It's free, it's incredibly easy to understand, and support for it is never going away.
The O'Reilly minibook Programming with curses (which I used to think was a "Unix-Hater's Handbook"-style thing) is a great place to start. Good luck.
spawn_of_yog_sothoth
go grab a copy of turbo vision for unix. it's on freshmeat. it's a port of the old borland turbo vision text gui toolkit for dos.
it's in c++, not c, but it wouldn't be too difficult to make a c binding. or just use c++.
whatever you do, don't use curses. it sucks rocks. unless, of course, your app only needs text entry widgets and buttons.
if you must use curses, at least use cdk (curses development kit) which makes the life of the curses programmer much easier. the maintainer was very responsive to the issues i encountered when using it.
---
Try something like Xterminal if you are using C++, or CDK or Newt otherwise. These libraries are typically built on top of ncurses and/or Slang, sort of like how Qt/Gtk+ are built on X Windows.
And that the "user interface" is little pictures of food you touch to select?
The moral is that the dumber the interface, the better. Even using a mouse is a learned skill that cashiers might or might not have learned. And using the tab key to cycle between options? Forget it!
Pushing simple buttons is the only answer. If you can't work with a touch-screen, the old reliable Function Keys are your next best bet and seem very popular in POS systems. Of course, don't forget to paint them different colors, and have them custom-covered with key labels like "New Customer", "Visa", or whatever...
To all intents and purposes, you have to design a POS system as if the user had never SEEN a computer, let alone learned anything about them. Fortunately, text-based displays work well with push-button input systems, but before you worry about what your going to draw on the screen, figure out how the brain-addled user is going to tell the system what to do.
paul
Silly Rabbit, sigs are for kids.
note that he has abandonned his own system for now.
You sissies and your monitors...why don't you program like real men, using flashing LEDs to let you know what's going on.
Ahh, you too have no idea how coddled and pampered you really are. When I learned to code, LEDs weren't yet in widespread use, and all of the computers used HEDs (heat emitting diodes) for status displays. The only way to tell if a bit was set was to touch a HED and see if your fingers got burned. It was no fun at all coming off of an all-night hacking binge with my fingers covered in tiny pinpoint-sized burns from a particularly gruelling debugging session, only to go to work for twelve hours manufacturing watch springs in a dangerous sweatshop just so I could afford the computer time and a bit of coal to fuel young Timmy's iron lung.
I'm just glad I wasn't there the night that some fool decided to mess around with the system clock multiplier, causing all the HEDs to set fire to the console, burning down not only the data center but also two adjacent nursing homes and a Salvation Army warehouse used to store surplus 72oz cans of bean w/bacon soup.
Reservoir Zigs
CDK is a curses "widget set" which is marginally useful. It's easy to throw a pretty application together with it, but for large scale apps it becomes a bit of a struggle. Any dynamic sizing or placement information is left up to the application and the API is such that changing widget attributes post-initialization is a challenge.
Regardless, it's logically structured and the code is simple to dig in and hack on. I think the official site is:
http://www.vexus.ca/CDK.html
It's not event driven, however, and as my app grew it made me long for a terminal version of GTK...
You should probably take a look at http://www.viewtouch.com/, which is a linux based pos GUI menu system. Granted its GUI, but it might be a good start to work on implementing a text based front end for their stuff. I haven't looked at it enough to give you a much better review than that, but I'm laying odds it'd help you achieve your goals or at least provide a good starting point. The code is GPLed, last I checked, and you can download it to check it out.
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
Ah, none other than the Jamie Zawinski (of netscape/Mozilla/Lucid Emacs fame) has been working on this particular problem.
m l
Check out:
http://www.dnalounge.com/backstage/log/2001/02.ht
Where Jamie provides a pointer to:
http://www.linuxcanada.com/linuxpos.html
He also took a swipe at hacking up his own Linux based POS system:
http://www.dnalounge.com/backstage/src/pos/
- Any Day above Ground is a good Day (Michael Rich, 1997)
Here are your requirements/what you got:
1. Text-based POS system
2. Written in PowerBasic
3. Want a free version under Linux
You say you want to redo it in C - are you sure? Do you have anything to gain by porting it? Perhaps speed - but does it need it? Maybe a re-write - but does it need it?
It doesn't sound like you will gain much, other than a learning experience. I would say if you are going to have to rewrite it, and you want to make it free, you might as well go all out, and do it in style:
Perl/PHP and Apache, with some MySQL or similar free DB on the backend (if needed). You could even provide a web interface if needed.
If not this, why not just leave it as BASIC code? Download a copy of XBasic, and compile - a little will have to be changed (if you use any inline assembler, that might need tweaking), but not as much as doing a complete rewrite in another language...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
And, some ever helpful links:Turbo Vision For Unix and Turbo Vision. Two different ports. Judging by their freshmeat entries, I'd go with the second one.
GPL made simple: What was my stuff is now our stuff. If you improve our stuff, please keep it our stuff.
For desktop applications, you're right, but for Point of Sale applications, it's a different ballpark. The user is going to be an employee who is trained in how to use the application. It should provide an interface that is simple and lets the user (cashier, usually) perform their job. Widgets, popups, etc are distracting, not helpful; there should be one simple way to do something and the interface should remain relatively stable and simple. POS apps are different from desktop apps.
Along the same lines, I have been thinking for a while about a single simple API with multiple backends so you can write an app once and it will either target curses, gtk+, qt, win32 etc.
Obviously I'm talking about seriously simple GUIs here with nothing much more than a few input fields and some validation. No cross-widget realtime updating or drag & drop etc.
Maybe it wouldn't be much use to most ppl, but these are often the kind of simple apps I find myself writing. I think configuration tools would be a good example that could gain from this. (also, I have just thought, how about a HTML backend !?)
I guess my point is that people seem to be choosing ever growing widget sets and committing themselves to an API which is often way more complex than they need. If some ultra-simple, multi-targetted API was available people might run your app in future in ways you didn't possibly imagine.
Maybe I'll start designing it myself some time soon....
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
I would like a way to see all comments that have recieved positive moderation, regardless of their actual score.
- - - - -
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
PicoGUI is a GUI for embedded systems I've been working on for a while. It's video library is pretty flexible, so much so that it can render to ncurses! This means that PicoGUI apps can run in text mode almost the same as they would run in a graphical mode. The advantages would be a capable GUI that's in active development, and an easy upgrade path to a graphical system. Oh, and it's client-server if that helps. PicoGUI has client libraries for C and Perl, and more languages will be coming.
Some disadvantages though... Currently the keyboard tabbing isn't fully functional, and mouse input probably isn't applicable here, so you might have to do some funky coding to move the focus from field to field, etc. Also, it's a relatively new GUI so it might be missing features here and there.
-- 2 + 2 = 5, for very large values of 2
"I first want to deploy it using a terminal interface instead of a GUI interface for the simple reason that there will be times when it's better to run thin machines without installing X11, and it might be easier to implement rather than jumping right into GTK or some X11 widget toolkit. So does anyone know of any character based UI libraries that are available for C?"
Have you looked at the ARACHNE Web Browser for Linux it requires svgalib on a 486 with 8MB of RAM, but allows you to design your whole interface in standard HTML since its an HTML/4.0 specification compliant webbrowser. The Linux version is still in alpha/beta stage, but the DOS version can run in Linux using dosemu.
I wouldn't call it a Non-GUI platform, but it is a low resource X11-free platform.
Work for Change & GET PAID!
Development time is no issue... it is quicker to design a GUI using a guibuilder than it is to code something in curses.
And even if there were a curses-based guibuilder, why would you want to use it?
Sure, there are certain tasks that are better suited to the keyboard and the command line, but the graphical interface is popular for a reason: when done properly it works, and it works well.
Why anyone would want to give up those advantages is completely beyond me.
-p.
Actually most command line applications (or interfaces) are more capable than GUIs because they can be scripted. Capable is not the keyword for GUI. I prefer user-friendly. The only thing GUIs can do that you just can't do in a command line is graphics. Hence, WinCVS's cool branch graph that isnt in the commandline version.
Someone you trust is one of us.
A CLI is the lowest common denominator for a user interface to a software package. A textual interface with few or no cursor control sequences guarantees accessibility, without any concerns about incompatibility, 8-bit clean transport path issues, or dependencies on functionality (such as certain X display calls) which may be omitted on certain client implementations, or which may be ambiguously defined in the specs and implemented differently on different clients.
For low-level configuration of a system, a CLI is mandatory. This is why Cisco and every successful router and switch company offers a command-line interface that gives access to all facets of device configuration.
With a CLI, I can control my system from anywhere, with the most minimal of interface hardware and software, and no nasty suprises.
I do not deploy Linux. Ever.
Better yet, if Power Basic becomes available for Linux, you can port the code to Linux of you still have it. It was rumored on the Powerbasic sites that they were devloping a version for Linux. Not exactly sure, but that would sure make life easier! :) I have a coworker who swore by Powerbasic. He evn was going to buy a HP LX100 and move a app he created in powerbasic to it. The app he created was his own, personal DOS based PIM. It was programmed to HIS specs. You see, this guy is an albino, and his eyes suck (sorry Jim! :)). Console mode is the best for him to see, becase it's the clearest. He runs 640x480 because it's what he can see. He can't see the higher resolutions. Outlook, Groupwise and any other PIM was too hard for him to read under windows. Only thing that might make his program better is if he had Palm support, but he'd never do that because he can't read palms either.
Gorkman
Think of how nice it would be for them to be able to update their apps to something more modern, running on a Linux server which is far more interoperable than a Netware server. Cuz yes, while they might want to cut costs with their computers, it might make sense to have the *server* networked with some central location and sharing information with them.
With this sort of situation in mind, they can keep their old terminals, and either boot with DOS, launch a TCP/IP stack and telnet application, and connect to the server, running console applications from there (remember dumb terminals?), or maybe, if the computers are fast enough (small 386's will do), do a diskless linux boot from the server and have a much neater and less archaic solution.
However, the question arises, if all is working well under the current Novell setup, why change? well, the answer is: it's getting harder to find someone who knows Novell, and easier to find someone who knows Linux. AND yes, after all those years, the Novell boxes are starting to crap out.
off the top of my head, i can think of two companies I know which could (or do) benefit from having a way to develop a modern app in text-mode. One of them is a freight company which has a centralized system on a DEC Alpha server and has all the branch offices connect via frame relay. Had they needed to upgrade the 386 terminals in the branch offices, it would have meant they couldnt afford to link all the offices together. And i can tell you those 386's WONT run any graphical environment but work in textmode just fine.
The other is a hardware shop with at least 4 locations, running Novell based setups and requiring constant attention because the Novell servers are crapping out, and Novell admins are scarce in that town. A Linux text-based solution would be interesting, because they can more easily find Linux people, plus, at least in my experience, Linux is more stable; i've had Linux servers working without flaws for so long, when they actually needed me to go down there, i'd forgotten how to get there :)
I'll stop ranting now. :)
You can't get it, of course. It was never offered as a product, or else it would have had some other name.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
While I agree that using a keyboard is faster and more intuitive for data entry than using a mouse, might it not be faster to write the application designed with the touch screen interface in mind. You get the best of both worlds with a GUI presentation, and keyboard speed?
AF-Design, web development.
For the on-topic portion of this comment, let me suggest that there is really no reason to do a pure text based GUI anymore. Text based GUIs were invented largely because of limitations in the hardware, which have all must disappeared. These days, the term "Glass TTY" has about as much pertenence as "Horseless Carrage".
Just about ever normal GUI is still able to do text, so if you want a "text only" application, you certainly can get the same functionality, plus benefit from better tools cross-platform functionality, etc.
As far as joq is concerned, I find that browsing at +1 manages to filter out most of the crap pretty well. I wish moderators would spend their time modding up +1 posts to +2 instead of modding down +0 posts to -1, but there isn't much anyone can do about that. It's their mod points after all.
Trolls will be trolls. Ignore them (or read them at -1 if that amuses you). But don't take it seriously.
blessings,
"Only in their dreams can men truly be free 'twas always thus, and always thus will be."
--Tom Schulman
OH!!! I all this time I thought people were calling me up trying to sell me a Piece Of Shit!
Ok my karma is maxed out. When do I become Enlightened?
And then there are those of us who started out wiring tabulating-machine plugboards. Getting an IBM Model 84 Collator and a 402 tabulator to write poetry was tough. So there.
You're right. Learning the querty keyboard layout, and the three-symbol code for each product would be infinitely faster than learning the register layout, and the one-symbol code for each product.
And, as a special bonus, they'd be able to put friendly, ergonomic 101-key keyboard on the counter, instead of that unisightly thing that looks like a cash register.
Not only that, but when they were running specials, everyone could be trained beforehand on the new three letter codes. If someone forgets, they could just call over the manager -- what would that take? Five minutes, max? It feels more efficient already. Just putting the new picture on the register would mean that learning the new register layout would take a good 10 or 15 seconds for anyone with a brain -- it's just to much work to imagine.
Slashdot is jumping the shark. I'm just driving the boat.
Most of these languages provide nice wrappers around curses or even a full-fledged X interface.
Tired of losing real money in a bear market? Try Peak Trader.
Use the library that Dopewars(tm) was created with. At least your GUI will be addictive.
Moderators: This is an attempt at humor (albeit poor, i agree).
"My mother never saw the irony in calling me a son-of-a-bitch." - Jack Nicholson
How easy would it be to develop a text-mode application that has a UI that is just as capable as any GUI?
Quite easy actually. I've been doing a lot of ncurses programming lately. You can do some amazinly elaborate things with it if your a good programmer. A good technique really pays. If you start running into situations where you're brute-forcing it, I advise that you back off and do a little work on a good "framework" for your app(that's one minus about ncurses, there's very little "flamework").
Some key points about ncurses:
o It's very fast - Text mode applications are great for productivity. Their GUI counterparts always turn out to be slower for some reason. ...etc.
o Menus and Forms - The menu and form libraries are standard on UNIXes. You can fairly easily create fields for data entry that have built in validation routines
o Tables - Well, not exactly, but a clever way to make a very snappy table is to just use a menu. In text mode you can't tell the differnce. Ncurses menu-tables are more than what the Java 1.1 AWT library provides
o Well established - Curses programming has been around for a long time. The characteristics of many terminal types has been worked out(by ESR) and abstracted into the terminfo database. Its quite portable.
o Works Anywhere - You can run it over telnet, ssh, or just dump bulky X alltogether and run on the Linux console.
Here's some links:
Ncurses Intro by Eric S. Raymond and Zeyd M. Ben-Halim
Linux Journal Artical by ESR
Fujitsu ETI Programmers Guide
SCO ETI Programming
I really wish people would concentrate more ncurses programs. They're just damn efficient. Anyone who uses mutt and slrn and such knows what I'm talking about. If you're really clever, you'll librarify whatever it is that your working on so you can hook on a GUI version later after you've tweeked the behavior of the app without wasting a lot of clock-cycles on graphics programming.
I've used S-Lang considerably in the past on projects which needed a TUI. It was intuitive and had a very slight learning curve.
Check out http://www.s-lang.org/
The CLI (Command Line Interface)... aka, "text mode" is alive and well. In fact I maintain a text mode application for my job. There are still several markets that prefer to employ CLI vs GUI. In fact, any place where data needs to be entered quickly and effectively, GUI can't compete.
Unfortunately, Microsoft is making it harder and harder for us to operate our programs on the winX operating systems. Every new version of windows brings us more incompatibilities. I think it's a mistake in microsoft's "strategy" to phase out the console, because text mode programs still have a place in the computer software market!
Good choice going with Linux. When microsoft rubs out the CLI completely, they will lose an important industry segment.
Remember, just because a program doesn't have flashy graphics, doesn't mean it's old and hard to operate.
Skiers and Riders -- http://www.snowjournal.com
Don't you think that...
Developing Attractive non-GUI Apps for Linux
is better than...
Developing non-Attractive GUI Apps for Linux
I'll see your senator, and I'll raise you two judges.
That most people *like* GUI's for when they're using a program. While I probably would have little problem going to a text-based interface (I grew up with DOS, after all), but I'd imagine most people who would be using a POS system wouldn't find it as natural.
I guess it's rooted in one of the rules I've learned since becoming a web developer... People Like Widgets, Buttons, and Pop-Up Windows all in Pretty Colors Complimented by Ugly Animated Graphics .
Sad but true. :-)
What's a sig?
Few people in this industry want to invest in a GUI interface, and won't for probably another decade or so. The screen is 15 x 15 (characters) and what we do works well: receive shipments, send shipments, move shipments, etcs.
TUI is going to be around for a long time yet. We use Perl and VB. We'd migrate to Linux in a second, if customers would buy it. Given time, they will. But for now, we use Win32...
information is immaterial
Forget your grandfathers' 8086, here's a dusty, late cold-war relic: Raise your hand if you still remember GEOS for the Commodore 64.
The main assembly language support consisted of routines to read/write a line of video in and out of string variables, which had to be presized. Everything else was written in BASIC and ran like blazes on a 286.
Brackets contain world's first nanosig, highly magnified:[.]
Most volume data entry people use only one application all day long, and a GUI does nothing to improve their productivity.
Ternimal/Console based applications are alive and well in the data entry arena, and until a GUI can improve (instead of decrease) productivity test based interfaces will be the platform of choice for volume data entry.
Text apps can also be run via ssh over slow links with good performance, and without any tricky X configuration.