Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Developing Attractive non-GUI Apps for Unix?

Cliff posted more than 13 years ago | from the ease-of-use-doesn't-necessarily-mean-WIMP dept.

Linux 150

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?"

cancel ×


Sorry! There are no comments related to the filter you selected.

Re:Scripting Language (1)

Anonymous Coward | more than 13 years ago | (#234934)

Although you may have a valid point here, the poster said he wants to brush up on his C skills. I'm assuming he needs the C knowledge for the school he will be attending. Although these languages share some similarities with C, they are not C and will not help the poster accomplish what he intended to do.

Re:Why use text? (1)

Anonymous Coward | more than 13 years ago | (#234935)

Simplicity. Both in devlopment and use.

Re:Curses (1)

Anonymous Coward | more than 13 years ago | (#234936)

Colour is in EXTENDED XSI Curses and is supported by many curses implementations, including ncurses. BASE XSI Curses provides windowing and widgeting behaviour. forms and panels, ncurses extensions, from handy high-level functions for pretty much what they sound like: forms provides forms (so you don't have to keep all those widgets straight); panels provides overlapping windows (basic curses windows are I guess not "windows" in the classical sense, so you would want to use panels).

What we really need (2)

Anonymous Coward | more than 13 years ago | (#234937)

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

Python text interface libraries (4)

cduffy (652) | more than 13 years ago | (#234939)

If Python's your game (and it should be!) you can find some Python textual UI libraries at: 43256747 (remove the space, slashdot put it in).

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.

Re:Not for me. I love this topic. (1)

Caine (784) | more than 13 years ago | (#234941)


Question 1:

On Water Paradox's homepage at he seems to take a strong dislikening at the Scientologists for trying to force their views upon other with legal matters, while he himself tries to force his views on other with retorics and mythology. Is any way better or worse than the other? Why do you think Water Paradox makes a difference between Scientologists and their views, and Christianity and their views? Is one more dangerous than the other? Why or why not? Discuss.

better (maybe you'll agree) (1)

On Lawn (1073) | more than 13 years ago | (#234942)

is to write a program that is user-interface agnostic and then write user interfaces for it. I've been working on your proposal for almost three years now, and to a limited degree you can do it. But then you get into windowing issues, state issues, what do you do if they want graphics issues and wind up doing it server/client anyway.

Besides, on the gnucash mailing lists I see a effort towards this lately. A multiuser gnucash. But then tunneling from the other end of the mountain is EJB architecture. I'm not sure where they will (or even if they will) ever meet but they are working on the same problem. (As an aside, for now at work I am forced to using Microsoft Exchange, queryable folders, web components, digital dashboards, etc in this fashion but I'd rather use Java ejb architecture. *Much* more flexible and intuitive and solid. We're strected out like plasticman-on-twister running to make it through all the hoops in the way we have to make it through them.)


One word: Emacs (3)

Just Some Guy (3352) | more than 13 years ago | (#234944)

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:

How do I enter a sale?

Is it because do you enter a sale that you came to me?

Duh. How much do these jeans cost?

Does it bother you that much do these jeans cost?

Hell yeah! My boss is gonna kill me!

This is not a healthy way of thinking.


When did you first know that much are the damn jeans?


Can you elaborate on that?

Die slowly.

Are you annoyed that you, too, may die someday?

Suggestion: TurboVision (3)

docwhat (3582) | more than 13 years ago | (#234945)

Now that good old TurboVision is open source, you can use it: TurboVision on FreshMeat []

Take your pick: GPL or BSD Licensed. :-)

Ncurses (2)

Dogun (7502) | more than 13 years ago | (#234947)

Ncurses is really great.
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...
Those should help set you on your way.

Now if only someone would make an AAlib Xserver.

Re:Keyboard vs. Touch Screen (1)

sacherjj (7595) | more than 13 years ago | (#234948)

I designed touch screen based system used to control industrial gauges. The single biggest annoyance with touch screens are the distance between the display LCD and the touch sensor. This creates an offset that is different for each height of person.

For example: A 6'5" person (myself) configures the screen and intializes the touch screen. Now a 5'1" user walks up to that same screen and must tap over top of my locations to hit the same spot. This requires the buttons (or atleast the hot spot detection) to be very tall.

All of the gauges would be much faster and easier to use (let alone programming and setup) with a keyboard only solution. But the industrial PC touch screen was "the in thing". What are you going to do when they want a 1/2 million dollar gauge. Yep, you give the customer what the customer wants.

Others will surely have suggested this... (3)

HP LoveJet (8592) | more than 13 years ago | (#234949)

...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.

turbo vision (2)

Phexro (9814) | more than 13 years ago | (#234950)

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.

Re:What Linux needs is some GUI but non-X-based ap (1)

killbill (10058) | more than 13 years ago | (#234951)

Like hell offtopic... thats a good suggestion...

A related question would be to consider lynx, and just code your app up as all cgi based with a central apache server.

Lynx gives you the "gui", and you can support both text and graphical terminals, you have the ultimate in portability, and you client server architecture is completely a done deal for you.

Totally flexible, totally portable, totally scalable.


Re:Totally Offtopic but needed to be posted (1)

Lysol (11150) | more than 13 years ago | (#234952)

It's just not about text tho, it's about how the modern GUI - which we pretty much equate with a workstation - sometimes isn't always practical.

I say this mostly out of experience with the last system I built. Think if you worked at a snack bar at a baseball game. It;s not very feasible to be using a mouse and clicking on a bunch of buttons to enter and print stuff out. This is where, in my opinion, TUI or touch screen is king.

It's the same principle behind the argument that console people use when they might face off with Mac or Windows people. How in a lot of situations, keystrokes are faster than mouse and menus.

And another thing to consider is X configuration issues and possible assocatiated hardware and troubleshooting costs. If you can get a Linux login prompt up, then the system should work. No acceleration, no fancy buttons and widgets and no need for a mouse.

Re:The problem being... (1)

Photon Ghoul (14932) | more than 13 years ago | (#234953)

I disagree. I've never developed a POS, but I've given it some thought and watched users of POS systems closely (not serious research, though). It seems that what they would want the most is an easy-to-use interface that has intelligently laid-out hot-keys to make it easier to fly through screens/windows.

Re:Keyboard vs. Touch Screen (1)

Photon Ghoul (14932) | more than 13 years ago | (#234954)

There are many POS systems using a touch screen for input. I think the problem with that is that it requires special hardware - where a keyboard input device could work on any old P.O.S. (that's a pun) system.

Re:Dumb it down. WAY down... (1)

paul7e (17646) | more than 13 years ago | (#234957)

>>>But ya know what? If people working at mcdonald's could type, even just a little bit, the order taking would be incredibly streamline

You are oh-so-correct.

However, I'm betting that Ronald and the other clowns at McD's have spent a lot of time and energy calculating the cost-benefits of training their flunkies to type vs. "push the pretty picture".

Sadly, I think the evidence is that dumbed down wins. Their mascot isn't a clown for nothing.

Dumb it down. WAY down... (3)

paul7e (17646) | more than 13 years ago | (#234958)

Ever notice that there isn't a mouse attached to the register at McDonald's?

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.


Re:wussies (5)

double_h (21284) | more than 13 years ago | (#234960)

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 []

Re:Curses (1)

Bob Dobbs (21396) | more than 13 years ago | (#234961)

I think another big bonus to curses is that it's most likely already going to work on any flavor of *nix or terminal type you encounter. There are certainly newer and fancier libs than curses, but if you need portability across OS and possibly terminals, it's hard to argue with curses.

use lynx (1)

djinn87 (24245) | more than 13 years ago | (#234963)

if only lynx [] had dhtml/javascript support ...

Re:The problem being... (1)

egon (29680) | more than 13 years ago | (#234966)

While this may be a true state with regards to visual attractiveness and preference, it doesn't take into account usability issues.

Having to move your hand between the keyboard and the mouse frequently is extremely inefficient.

Give a man a match, you keep him warm for an evening.

CDK Works (2)

chaumu (31122) | more than 13 years ago | (#234967)

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:

It's not event driven, however, and as my app grew it made me long for a terminal version of GTK...

A company to check out: ViewTouch (2)

hardaker (32597) | more than 13 years ago | (#234970)

You should probably take a look at [] , 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.

Linux POS System (5)

SirShadowlord (32925) | more than 13 years ago | (#234971)

Ah, none other than the Jamie Zawinski (of netscape/Mozilla/Lucid Emacs fame) has been working on this particular problem.

Check out: l

Where Jamie provides a pointer to:

He also took a swipe at hacking up his own Linux based POS system:

Great Linux POS System (1)

Racher (34432) | more than 13 years ago | (#234972)

This a really well done Linux POS system that has been done here. It is really top notch...

Check it out here [] and a Screen Shot is here []

...and I'm not sure we should trust this Kyle Sagan either.

Re:Scripting Language (1)

Zurk (37028) | more than 13 years ago | (#234973)

code it in C using FCGI. that should take care of the problem of learning C. Also with a browser based interface using lynx for text and netscape for graphics will handle the reusability issue.

Re:Since gfx gui and txt gui API? (1)

p3d0 (42270) | more than 13 years ago | (#234976)

how about a HTML backend
Er, how about HTML as the front-end? There are browsers for all kinds of widget systems, including a text-based one (ie. Lynx).

Hmm... (2)

cr0sh (43134) | more than 13 years ago | (#234978)

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!

Re:Keyboard vs. Touch Screen (1)

Sogol (43574) | more than 13 years ago | (#234979)

TCL/TK combined with a touch-screen would be perfect for POS applications.
Has anybody seen a touch-screen work with Linux?

Re:Gesture System? (1)

Pedersen (46721) | more than 13 years ago | (#234981)

Actually, I, personally, am dog slow with writing of any sort, and always have been. Typing is the only way I can keep up, which is why I bought palm pilot keyboard (one of the stowaway folding keyboards :)

Re:TurboVision is one (2)

Pedersen (46721) | more than 13 years ago | (#234982)

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.

Re:The problem being... (2)

ddstreet (49825) | more than 13 years ago | (#234983)

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.

TurboVision is one (1)

ppetrakis (51087) | more than 13 years ago | (#234984)

It's been ported to UNIX. There's a version out there developed by someone that lets you write an application in TV and that will support Console and X11 (using QT). TV is what is used to build Borland's fine Turbo Debugger GUI, For all you TASM fans out there. I've been told Slang is a MUCH better alternative to curses though I've not coded in either. I havent done console programming in a loong time and want to keep it that way :-).


Since gfx gui and txt gui API? (3)

MartinG (52587) | more than 13 years ago | (#234985)

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....

How about a GUI without X11? (2)

Cy Guy (56083) | more than 13 years ago | (#234989)

"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.

Turbovision (1)

jkujawa (56195) | more than 13 years ago | (#234990)

Turbovision is a very nice C++ (Also Pascal, but I'm not sure if that's been ported to Unix) library, originally written for DOS by Borland, but now ported to Unix. Borland was nice enough to release full source for it around 1995, when they pretty much dropped the DOS targetting for their compilers.

Turbovision was the first application framework I ever used, and I have really fond memories of it. It was a hard way to learn C++, though. TurboVision under Turbo C++ 3.0, senior year of highschool, the first time I ever wrote code for money. It was ... glorious. []

Re:What we really need may be hard to find, but... (1)

matthewd (59896) | more than 13 years ago | (#234991)

...depending on your system requirements, you might take a look at the Data Access [] product line, which includes character mode development environments for DOS and Linux/Unix (DataFlex), a GUI development environment for Windows (Visual Dataflex), and their WebApp Server for web based applications.

This is a high level "4GL" OOP development system, which we've been pretty happy with. Over the years we have moved from CPM (Data Access goes back a ways) and DOS character based "procedural" style programming to (briefly) the OOP character based system, and then to the OOP Windows development system we are using now.

If you must develop database type applications for multiple environments, a strength of DataFlex is the fact you can put business rules in the DataDictionary class definitions, and these will be enforced regardless of the underlying database (their proprietary DB, DB2, MS SQL, or any ODBC accessible database) and the overlying (if that's a word) GUI (character, Windows, Web).

I can't comment on creating a single user interface description and having it applied to different interfaces, as you point out some things do not translate well from one interface to another. Especially when things get more complicated... at least in the DOS/Linux and Windows environments you do work with a similar set of classes (I was actually quite happy when I started using Visual Dataflex because so much of my knowledge of the classes and framework translated straight over).

The WebApp server, btw, is designed to run on NT/IIS. However I think the newest version which is now in open beta has been redesigned to run on Linux/Apache/Java)

Totally Offtopic but needed to be posted (1)

joq (63625) | more than 13 years ago | (#234992)

This whole "Holy War" against the people here at Slashdot has got to stop sometime soon. What ever happened to the older days of about 2 years ago [] (random link I found no significance to anything) when things were cooler and calmer, there were no goatsex posts, no little morons running around babbling on like idiots. When someone posted worthy information worth reading.

All I see nowadays are immature idiots posting goatsex, spork, bs music information which wastes so much time, and money via way of bandwidth to process that bs. Get a life no one wants to hear about what problems you may have with Jon Katz, Timothy, Michael, Rob Malda, or whomever else posts an article here.

They work here you don't and thats the bottom line, don't like it then type in another URL in your browser, and that will solve the problem.

Even if you have a pile of diamonds equal to the weight of this earth there is no way to compare the peace it provides to the peace afforded by inner development. The owner of the jewels is still beset by mental problems like anger, attachment and so forth. If someone insults him, anger starts to rise, followed by, thoughts to give harm, to insult, to hurt. The man of inner development reacts quite differently. He thinks: "If he got angry with me, insulted me and hurt MY mind, how upset I would be, how unhappy I would become; so I shouldn't do negative things to him. If I am angry with him and insult him, he will be terribly upset and unhappy. I become unhappy when he is negative with me so of course he will be very unhappy and his peace will be disturbed if I am negative with him. How dare I do this to him?"

When you think like this, the anger disappears like a popped water bubble. At first the bubble seems to be as solid as stone but suddenly it disappears. At first it seems to us that we can't change the mind; yet when we use the correct method, when we meditate like this, the anger goes like a water bubble. You don't see the point of getting angry. You simply practice patience, try not to let anger arise, try to remember that what disturbs your mind and destroys your happiness also disturbs the other's happiness and doesn't help at all. Then how beautiful your face becomes! Anger makes us completely ugly. When anger enters a beautiful face, no amount of make-up can hide the complete ugliness and terror that manifest.

We all love a good joke here and there, but attacking someone based on unfounded bs is annoying and downright immature, and can be construed into slander, and libel a crime nevertheless.

Put yourself in the Slashdot staffing position. Provide a neat tech site where information isn't as watered down as it is on sites such as MSNBC, or CNN, along with the opportunity to interact with others who have enough knowledge and talent to run a government if talents were combined and applied. All that for free to the people who browse here.

Wouldn't it be nice to just focus on a subject, and get insights into the way people see things while adding positive input, or providing someone with an answer to their question, or even correcting someone about something they may have taken out of perspective? Its not even a matter of becoming something of a tightwad ass site like FreeRepublic [] or a pencil pouch wearing stereotypical geek site.

Slashdot used to be fun, still is when we sort through a 300 post thread only to find about 75 posts even relevant to the actual article. Its saddening to see this is going to become a joke if things don't change. This isn't someone's Geocities, Tripod, Xoom, "h3ll0-1'm-4-h4x0r" site, we all know its a hell of a lot better than most of the other sites out there. Yet many idiots seem to think that its some fscking loser site to voice their stupid fish, spork, goatsex, and other oddities. Grow up already do something positive for yourself such as reading an RFC or something insightful.

Shit even I joke many times [] , but I won't dwell on posting the same redundant shit over and over and over its sickening as hell. Posting something as anonymous is even more moronic. Who gives a shit about karma? Say what you have to say what you feel is relevant if you get moderated down, who cares, it didn't take away a drop of blood from your body, or a dollar in your pocket did it?

joq | deran9ed

Re:One word: Emacs (1)

idistrust (66924) | more than 13 years ago | (#234994)

Oh god that's great. You've just inspired me.


Re:Younger generation? (1)

yesthatguy (69509) | more than 13 years ago | (#234996)

I think the younger generation isn't as much a reference to calendar age, as how long one's been using a computer. Kids my age (16) who have been interested in computers for more than four or five years definitely used, if didn't grow up on DOS. Additionally, many elderly people have only been using computers for a very short time, and are hardly even accustomed to the GUIs of Windows and AOL..."command line" is a completely foreign concept to them.

hmm (2)

selectspec (74651) | more than 13 years ago | (#234998)

How easy would it be to develop a text-mode application that has a UI that is just as capable as any GUI

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.

Re:Curses (1)

Brama (80257) | more than 13 years ago | (#234999)

I agree. My first C program was 'connect-4', done using ncurses. All it took was 'man ncurses' and its related manpages.

I wrote a text-based mp3player using ncurses, called mp3blaster. It is equally interactive as fancy mp3players with GUI's.

(N)curses also has window-like structures, with borders, colours, and everything else. It understands most terminals, although you might find the number of keys that you can use on each keyboard is restricted (e.g. a single 'alt' cannot easily be read by a curses program).


Re:Curses (1)

RobNich (85522) | more than 13 years ago | (#235000)

Forgive me for being ignorant, but doesn't curses simply provide means to write the terminal/screen and accept input? I believe his question regarding the TUI library includes drawing windows on the screen in color. I actually wrote a library in C for DOS (~5 years ago) that does this. It also, if I remember correctly, includes support for controls in the window, such as buttons, text input. Allows for layering of windows and changing the Z-order. Like I said, for DOS. It uses inline assembly interrupt calls to write to the screen. But it could be ported to curses. Reply if you're interested.

text = cheap (3)

Roadmaster (96317) | more than 13 years ago | (#235003)

There *are* companies that can't afford new computers. Maybe not where you live, but think of other countries, and small towns within those countries, and shops that are big enough to merit having POS systems but not big enough to merit buying the latest whizzbang pentium 4 systems. I've seen plenty of those, and I'm talking about shops that still run a Netware 3.x server, using floppy-based DOS terminals to run some app written in dBase or FoxPro.

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. :)

Re:A company to check out: ViewTouch (1)

fsck! (98098) | more than 13 years ago | (#235005)

Stay FAR away from ViewTouch. This guy is a scam artist. None of the pictures on his website are of real products. One of them at least is even stolen from an article ZDNet ran a few months back about a TransMeta tablet. It is most definatly NOT GPL [] , either.

The overall low quality of VT products is exactly why JWZ was forced to come up with his own system for the DNA Lounge. When I was evaluating POS systems for a local night club, I communicated briefly with Jamie. Neither of us had any success getting VT to work at all, even after I had access to the source code.

Sadly, that nightclub ended up going with an NT-based solution becaus the Linux POS market was so barren. Ah well, hopefully LinuxPOS is mature enough to save the rest of you from that plight. I'm just glad my current employer doesn't deal with cash.


Ck -- Curses toolkit for Tcl (1)

dskoll (99328) | more than 13 years ago | (#235006)

I really like the CK8.0 Curses Tcl Toolkit [] .

It's an add-on for Tcl which uses almost the same syntax as the Tk toolkit, but renders using curses. If you're familiar with Tk and it's widgets, you'll be right at home with CK.

Textmode Quake! (1)

uglyduckling (103926) | more than 13 years ago | (#235008)

Slightly OT, but while we're [sort of] on the topic, there is a Textmode Quake [] package available which provides an interesting idea for user interfaces.
I wonder whether this could be combined with the Doom Sysadmin Tool [] for a text->GUI->text->severe eyestrain session.

Re:What Linux needs is some GUI but non-X-based ap (1)

Omega996 (106762) | more than 13 years ago | (#235009)

i think that 'links' might be a little better than lynx, insomuch as one can view frames, rather than having to guess at which frame you need, and then selecting it. just a thought. great idea using the web browser though. totally great idea...

Re:Not for me. I love this topic. (1)

Omega996 (106762) | more than 13 years ago | (#235010)

i'm trying to see how my beliefs in Kali the Eternal Mother and Shiva the Destroyer fits in with your holy ghost. sorry, not seeing it.

Keyboard vs. Touch Screen (2)

giberti (110903) | more than 13 years ago | (#235011)

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?

Research! (1)

DeeezNutz (114051) | more than 13 years ago | (#235012)

"If you've ever used a cash register, sometimes GUI stuff with a mouse is not the best...especially for end users"

There are tonnes of GUI based POS systems that don't require a mouse. Check out: Auto~Star [] and Breakpoint. []

Both of these systems have a GUI interface that do NOT require a mouse.

PS Breakpoint systems does not have their current system on their website, their current system is gui based :)

Re:Totally Offtopic but needed to be posted (2)

StevenMaurer (115071) | more than 13 years ago | (#235013)

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.

Curses (4)

Master Bait (115103) | more than 13 years ago | (#235014)

Just use curses. It is about the simplest lib out there. You really don't need a DOS workalike api. Really, it will take you about a day to get the hang of it.


POS? (4)

Ronin X (121414) | more than 13 years ago | (#235015)

Many years ago I wrote a POS (Point of Sale System)

OH!!! I all this time I thought people were calling me up trying to sell me a Piece Of Shit!

Re:wussies (2)

Animats (122034) | more than 13 years ago | (#235016)

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.

Re:CLI development (1)

igrek (127205) | more than 13 years ago | (#235017)

1) Text mode is not the same as CLI. Don't mix those concepts.

2) By some reasons, seems like it's much easier to write bad GUI than to write bad text-based UI. But that doesn't mean any GUI is bad just because it's GUI.

3) I don't think it's harder to operate our programs in Win2000 than in Win95, especially in regards to command line.

4) Going with Linux is good choice, indeed. However, CLI is definitely not the factor that drives developers from Windows to Linux. I have the same bash under both Win2000 and Linux and use the same perl one-liners.

5) Bonus trick. How to enable command-line completion in standard Windows 2000 command-line window:

Start regedit, find the word "CompletionChar". By default it's not set. To set <TAB> as a completion character, set the CompletionChar value to 9. That's all!

Re:What Linux needs is some GUI but non-X-based ap (1)

prog-guru (129751) | more than 13 years ago | (#235018)

Oh yes, the newest versions of this system were NT based, requiring 32 MB of RAM and a Pentium MMX processor and ~1GB of hard disk space. And the backoffice portion was FoxPro, multiuser if you map drive letters, as long as 2 people don't access the same file at once!

Re:Keyboard vs. Touch Screen (2)

mini me (132455) | more than 13 years ago | (#235020)

The touchscreen is a nice idea for some applications, but in the case of POS where you have to enter in, for example, the customer's name. In this case you'll end up having to take your hands away from the keyboard just to touch the screen which not only takes time, albeit not much, and it doesn't solve many more problems that a mouse could do.

On the other hand, I have see touch screens used in business' such as resturants and it seemed to work well, all they had to do was touch what was ordered and so on and it created the bill. In cases where data entry is limited to just touching what is being purchased then this is a good idea.

In the case of the former though I think a plain old text based "gui" would be ideal, if you're up to the task then nothing is really lost, and who knows it might turn out to be a killer app for Linux? And if not it still wont hurt to add to the plethora of Linux apps out there.

Re:Since gfx gui and txt gui API? (3)

mini me (132455) | more than 13 years ago | (#235021)

I've often wondered if a XML defined windowing system was feesable? Instead of calling windowing functions as we do now, one would define the GUI in XML (it doesn't have to be XML but since it's all the rage these days why not?) and then transport it to the windowing server at the network level (yes I know this is just basically X, but hear me out ;) this could then be easily implemented on different systems and programs can run with ease on all systems.
  1. The benifits I can come up with right now are as follows:
  2. Cross-platform capability - like I said above, if all systems supported this markup then they could display the GUI, whether that be a Windows machine or a UNIX machine, and you could even run the app on the UNIX machine, but display it on the Windows machine (and vice versa).
  3. The syntax would be mostly human readable and it should be even possible to do something as easy as echo "<?xml><dialog><button>cancel&lt /button></dialog></xml>" to display a window.
  4. The data wouldn't neccesarily have to go strait to the screen, instead it could be parsed by another program - an example of how this could be useful is grabbing all the text out of a window for instance, this might even lead to making piping of GUI apps possible!

I don't know how extesible this could be but I don't see why there couldn't be a drawing tag when you need to free drawings. For things such as bitmap graphics they could be included sperately like they are in HTML pages, they could just be sent in another request or inline if that would be better performance wise. Just some ideas, I'm sure someone who knows more about creating GUIs than I can comment on whether this would be possible and whether it would be a good idea or should we just stick to X?

Re:What we really need (3)

mini me (132455) | more than 13 years ago | (#235022)

I just wrote up a comment [] stating basically the same as this just mintues before reading this post. I believe an XML defined windowing system would be great! It could be cross-platform allowing UNIX and Windows (and other OS's!) apps to run on each others machines. (over the network even!) I also like how it could be converted to HTML pretty easily, I don't know if you want to go as far as using it for text based stuff, but why not eh? I believe we could also solve the piping problem that we have with current windowed apps using this!

Re:Curses (1)

mar22 (145944) | more than 13 years ago | (#235025)

One shortcoming of using curses is that you can not easily harness the whole keyboard. For example it is impossible by just using the curses API to operate a key like Ctrl+Shift+LeftArrow! There is a workaround for bare-bones text only Linux, but it is not easy and stright forward.

Scripting Language (2)

xp (146294) | more than 13 years ago | (#235027)

You could also use a scripting language like Perl, Python, or Ruby. On Linux Perl and Python are likely to come pre-installed so your program would also be quite portable across Unix systems.

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 [] .

Dopewars (2)

Lizard_King (149713) | more than 13 years ago | (#235028)

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).

Re:Suggestion: TurboVision (1)

KidSock (150684) | more than 13 years ago | (#235029)

Now that good old TurboVision is open source, you can use it: TurboVision on FreshMeat [] .

I just downloaded this and ran the demo on Red Hat 6.2. The characters where messed up and some of the key bindings didn't work. Granted, I didn't read the INSTALL but not a great start.

Ncurses Programming (5)

KidSock (150684) | more than 13 years ago | (#235030)

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.
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 ...etc.
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.

Have you considered SLang? (4)

Floody (153869) | more than 13 years ago | (#235031)

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 []

CLI development (2)

cr@ckwhore (165454) | more than 13 years ago | (#235032)

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.

Re:The problem being... (1)

FortKnox (169099) | more than 13 years ago | (#235033)

To add to this great comment:
I agree that GUI's make the younger generation happy (they never grew up in DOS), and if its speed of input you are worried about (what are the other disadvantages of GUI's?), then ensure that there is a way to run the GUI app without the need of a mouse (tabbing through the textboxes, stuff like that).

GUI's were created to make life easy for the computer illiterate, which is most of the business users this day and age. Eyecandy is what's in...

Gesture System? (1)

FortKnox (169099) | more than 13 years ago | (#235034)

What about programming it using gestures, like the miracles in Black & White [] , and other programs mentioned on /. a couple weeks ago. Its not GUI, doesn't need a desktop, but it does require use of a mouse...
If you could devise a standard, and if it could be taught quickly to the employees, it would make for a very very fast system (just how fast are you with your palm pilot writing? Same thing applies here). Plus, I'd like to see some code that uses this type of system...

Touch Screens SUCK! (1)

donutz (195717) | more than 13 years ago | (#235042)

My fiance and I registered at 3 different stores, and whenever you want to add something new to your list, you've got to print out a bar code from one of their touch screen gift registry kiosks. I don't even want to talk about how many times I had to hit the Backspace "key" on the screen to fix errors.

If I have this much trouble typing in the first three letters of my last name and first two of my first name...I can just imagine how bad these things would be in Point of Sale applications.

Stick with a keyboard!

. . .

The problem being... (2)

Jayde Stargunner (207280) | more than 13 years ago | (#235045)

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. :-)

Re:Younger generation? (1)

Evil Grinn (223934) | more than 13 years ago | (#235046)

What are you defining as the "younger generation"? I'm only 19 now and I DID grow up using DOS

"Younger" in computer experience, not biological existence.

Re:Since gfx gui and txt gui API? (1)

michaelo (224201) | more than 13 years ago | (#235047)

You know dialog? Its quite simpel - you write shellscripts which call dialog with various parameters and it e.g. writes the input of a textfield to stdout..
And AFAIK there is a xdialog too.. but it's not _that_ portable as you would like it..
Just thougt it might be of interest for you..
ha det godt,

Younger generation? (1)

quantum bit (225091) | more than 13 years ago | (#235048)

What are you defining as the "younger generation"? I'm only 19 now and I DID grow up using DOS, text-based interfaces, LangWin (a text-based windowing system for BASIC), and the like... Perhaps younger people who started using computers later may have started out on GUIs but I can definately remember when Windows 3.0 was nothing more than a novelty toy.

Re:Younger generation? (1)

quantum bit (225091) | more than 13 years ago | (#235049)

Haha, nothing makes you feel old like seeing people talk about DOS like it was centuries ago :)

The trouble with non-graphical is... (1)

Billy the Mountain (225541) | more than 13 years ago | (#235050)

you are typically limited to an 80 x 24 character format and usually monochrome. When you are doing POS, you have to make things intuitive because you are interacting a computer in a distracting and interruptive environment.

I think it's a mistake therefore, to forsake the GUI. For example, with a GUI you can make a tabbed interface to allow the presentation a lot of information without losing your way.

Also with a non-web based app, you're back to installing the software on each computer where it's going to be used.

What architecture would I use? JSP. (Check out jetty, a simple and free jsp server). Marlin

Point of Sale? (1)

mother_superius (227373) | more than 13 years ago | (#235051)

I've always thought it was Piece Of Shit

Re:Dumb it down. WAY down... (1)

SCHecklerX (229973) | more than 13 years ago | (#235053)

But ya know what?

If people working at mcdonald's could type, even just a little bit, the order taking would be incredibly streamlined using, for example, 3 letter codes for each food item.

Much faster than having to look down and find the damned button for that food item. You could also maintain eye contact with the customer as you took their order.

Oh well.

Re:Maybe I'm just bitter... (1)

Water Paradox (231902) | more than 13 years ago | (#235054)

Actually, it's pretty apparent to the rest of us.

Actually, a good question (1)

Water Paradox (231902) | more than 13 years ago | (#235055)

Curses on curses. We're developing a text-based UI from scratch in Perl using Win32:Console. Curses didn't work for us. Win32::Console works great, now that we got the up arrow moving the cursor to the previous field...

Shoulda used 'Preview' (1)

Water Paradox (231902) | more than 13 years ago | (#235056)

Hmmm. Now there's a lesson in using the preview button.

Why Text-based? (2)

Water Paradox (231902) | more than 13 years ago | (#235057)

We develop for wireless handheld computers used in warehouses which access a mainframe via middleware. []

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...

Curses (1)

arfy (236686) | more than 13 years ago | (#235059)

As some others have suggested, use curses.

I put together an inventory system more than a decade ago using curses. The company is still using it. Occasionally some of the employees complain about it not being a GUI, but the owner likes it because it's rock-steady stable and it works. And he isn't locked into a perpetual software/hardware upgrade cycle as he would have been with Windows.

GEOS! (2)

ScottBob (244972) | more than 13 years ago | (#235060)

Forget your grandfathers' 8086, here's a dusty, late cold-war relic: Raise your hand if you still remember GEOS for the Commodore 64.

TUI for DOS (1)

sinjin smith (245932) | more than 13 years ago | (#235061)

I used a system for DOS called Intuit (I can't remember the exact name. It was written in C, and was a complete windowing system. Very light weight and fast. I wish I code find the source for it again. I did port part of it to Unix. I was able to do edit masks and edit templates with a terminal. The neat thing about the system was that you could have all of your graphic output go through one function. Made things very easy to change.

Not such a big deal to write one (2)

localroger (258128) | more than 13 years ago | (#235064)

About 12 years ago I wrote a set of routines in mixed QuickBasic / assembly which implemented a windowing system like this. It had routines which would automatically size and center a window for an informational message, put up the equivalent of input boxes, and even supported scroll/select/edit lists. It was recursive (window over window) despite the fact that the language I wrote it in wasn't. As I recall this all required less than 1,000 lines of code.

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.

Re:The problem being... (3)

cannon_trodder (264217) | more than 13 years ago | (#235066)

I think sometimes people have been educated if not almost brainwashed into believing that point and drool interfaces and flashy graphics make for a better user interface.

But POS systems are fairly specialist. By removing excess graphics you can allow the end user to view the information they *need* in a clearly presented form. Anti-aliased fonts would be nice because higher resolution fonts can be more clear. Animated gifs don't really add any value though :-)

From an intranet development point of view, people like w.i.m.p.-driven interfaces as they're easy to learn but if they have to use them every day (possibly unlikely in a pure web field) they start asking for keyboard shortcuts because they're quicker...

If you watch a user on a unix-telnet system (like one used at a mobile phone company I worked for) you see them struggle to learn to 'archane' keyboard commands but once they have the experience they can switch between screens and get things done with almost amazing speed. The moment they we're 'upgraded' to a windows based system, they had to learn again.

The users never reach the levels of speed previously attainable because physically moving the mouse to the neccessary command buttons takes longer than, say, the time to move between keys on a keyboard.

Despite all this, I've still got to concede that 90%+ of all users, if given a demo of two new systems, will say they 'prefer' the graphical one over the text-based one. Talk about expensive window-dressing!

Re:POS? (1)

XMyth (266414) | more than 13 years ago | (#235067)

there'll be ok

The Dialog program + shell or perl script (1) (302388) | more than 13 years ago | (#235068)

Try the dialog program in combination with a shell or perl script. It is almost standard on every linux distro. Very fast and easy but not usefull for complex tasks :-(

GUIs don't help for data entry (3)

Old.UNIX.Nut (306040) | more than 13 years ago | (#235069)

A couple of Universities have done studies showing that even under the best of conditions that GUI based data entry is 15% to 20% less efficient for volume data entry than a text interface.

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.

Re:Since gfx gui and txt gui API?(Heretical Reply) (1)

tb3 (313150) | more than 13 years ago | (#235070)

The evil empire made it work. After Visual Basic 1.0 came out they introduced Visual Basic for DOS. I re-built Windows Apps written in VB 1.0 by just re-compling the source code. The programs ran fine on old 8088s.
O'course, then Microsoft decided DOS was 'dead' and VB DOS never got past version 1.0. But it was nice while it lasted.
Let the flames begin!

Re:Since gfx gui and txt gui API? (1)

tb3 (313150) | more than 13 years ago | (#235071)

Actually, it's been done, kinda. Forte for Java stores its Swing form layouts in XML format. Look for a .form file in your Forte project. I think Borland jBuilder does the same thing, too.

Why use text? (1)

gregfortune (313889) | more than 13 years ago | (#235072)

Have we forgotten how to add keyboard navigation to our windowed apps? Short of the perception that text based apps are more keyboard friendly, what other advantages do text based apps add.

And please don't pull the "But text based apps are the only thing that will run on my precious 8086 that's been passed down for three hundred years." The majority of machines will run a reasonably powerful windowing environment. Further, it a company cannot invest in machines that are less than 4 years old, perhaps they should stick with paper...

So the question still stands.. What do text based apps have to offer?

Re:Keyboard vs. Touch Screen (1)

Chakat (320875) | more than 13 years ago | (#235074)

The reason a touch screen is impractical is the old "Gorilla Arm Syndrome". After any real duration using a touch screen, your arm gets REAL tired. Keyboard entry is damn near perfect for PoS entry, as long as the interface is well designed.

Re:Why use text? (2)

gcalvin (325380) | more than 13 years ago | (#235075)

Text apps can also be run via ssh over slow links with good performance, and without any tricky X configuration.

Re:hmm (1)

dbCooper0 (398528) | more than 13 years ago | (#235076)

great .sig
Spinal Tap Rules. I saw them in concert in '8?
I agree with the text-based ideas posted here. I have clients with video-rental software that do very well without a GUI, and are quite happy...

POS Hardware (1)

elderbro (415415) | more than 13 years ago | (#235078)

There's a part of the POS world that been a bother. There are lots of thingies hung off most POS machines - cash drawers, bar code and mag-stripe readers, time-clocks, ... Any pointers or suggestions would be much appreciated.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>