Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Linux Software

Developing Attractive non-GUI Apps for Unix? 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?"

This discussion has been archived. No new comments can be posted.

Developing Attractive non-GUI Apps for Unix?

Comments Filter:
  • by Anonymous Coward
    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.
  • by Anonymous Coward
    Simplicity. Both in devlopment and use.
  • by Anonymous Coward
    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).
  • by Anonymous Coward
    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
  • ...because I came up with a concept [airwindows.com] based on text-mode xterms. This was inspired by the number of terms I've seen that allow you to zoom to larger or smaller fonts- with a term, the enclosing window gets bigger or smaller as well. The whole thing could be rigged to be a _flat_ 3D environment- you'd zoom stuff away from you to keep tabs on it in the background.

    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

  • by cduffy ( 652 ) <charles+slashdot@dyfis.net> on Wednesday May 09, 2001 @10:40AM (#234939)
    If Python's your game (and it should be!) you can find some Python textual UI libraries at:
    http://www.vex.net/parnassus/apyllo.py/808292924.2 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.

  • Sadly, that nightclub ended up going with an NT-based solution becaus the Linux POS market was so barren.

    Hell no: the DNA Lounge [dnalounge.com] 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.

  • Exam:

    Question 1:

    On Water Paradox's homepage at http://www.trios.org 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.

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

  • A bit off topic here, but I've been working with Ncurses for a while now, and I'm stuck. Ncurses is my favorite text-mode programming library, however, there sometimes comes a need to output an ANSI file to the screen and actually have it come out usable. However no matter how I try, I cannot get it to work. Either it comes out in pico-like escape codes, or otherwise completely unusable.

    Anyone know of any way to get ANSI-escape-coded files and Ncurses to cooperate?
  • by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Wednesday May 09, 2001 @11:36AM (#234944) Homepage Journal

    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?
  • by docwhat ( 3582 ) on Wednesday May 09, 2001 @11:14AM (#234945) Homepage
    Now that good old TurboVision is open source, you can use it: TurboVision on FreshMeat [freshmeat.net]

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

  • He's got some source code already [dnalounge.com], but he stopped working on it. If you can implement it, I'm sure he'd appreciate a copy [dnalounge.com]

    "Beware by whom you are called sane."

  • by Dogun ( 7502 )
    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.
  • 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.
  • by HP LoveJet ( 8592 ) on Wednesday May 09, 2001 @10:36AM (#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.
  • go grab a copy of turbo vision [freshmeat.net] 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 [his.com] (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.
  • 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.

  • 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.
  • 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.
  • 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.
  • Last I looked at it, Newt documentation was nonexistent. Documentation is a seldom appreciated feature, and it's hard to gauge a library's capability -- let alone use it -- without decent documentation. Also, it lacked a grid/table widget that I needed.
  • I know curses/ncurses is ubiquitous, but it is not a UI library. I don't understand why people keep recommending ncurses or Slang for application development: it's like recommending an axe and a cow when someone orders a medium rare filet mignon. A modern UI library -- text or graphics -- is far more than the ability to draw text on the screen, even with panels or windows. The UI widgets that we take for granted with modern UI libraries are completely absent from Curses or Slang: scroll bars, buttons, entry fields with masks, drop down menus, check boxes, radio buttons, grid controls ... etc. Even a touch screen POS will find many of these UI elements relevant.

    Try something like Xterminal [sourceforge.net] 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.

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

  • by paul7e ( 17646 ) on Wednesday May 09, 2001 @11:10AM (#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.


  • note that he has abandonned his own system for now.
  • by double_h ( 21284 ) on Wednesday May 09, 2001 @10:53AM (#234960) Homepage

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

  • 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.
  • > Qt Embedded runs off a floppy if you wish (thought about trying to get that running on a 486 I had).

    You underestimate the power of your old computer. My 486 runs XFree86 and KDE in its entirety. Sure it's slow, but it works just fine.

    But my grandest creation, as history will tell,
  • if only lynx [browser.org] had dhtml/javascript support ...
  • I remember GEOS. It also came out for the Apple II, IIRC. Here's one - remember the Tandy CoCo 2?
    Scott Jones
    Newscast Director / ABC19 WKPT
  • More and more software doesn't compile on FreeBSD on Solaris because the developers didn't take care to write portable code. Especially for text-based applications, it's worthwhile to write portable code.
  • 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 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...
  • could perhaps make an XML parser that could translate this into classes for an interpreted language like Python

    Do you mean Glade [gnome.org] plus libglade [gnome.org] with the Python bindings in gnome-python?

    Glade, other than generating C source for the GTK+ GUI you design, saves the file describing the GUI in an XML format which can be read via libglade. Then, it's only a matter of linking it in and calling a function which reads the XML file and builds the widget tree. The task of registering your handlers for the various events (i.e. a certain button pressed) can also be performed automatically by libglade, i.e. by looking at the executable symbol table for languages like C, or using the introspection features of the interpreter in the case of Python.

  • Actually, the C=64 was a great box for creating any type of text based GUI. With the graphic characters on the keyboard you could do some pretty cool stuff.

  • You should probably take a look at http://www.viewtouch.com/ [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.
  • by SirShadowlord ( 32925 ) on Wednesday May 09, 2001 @10:37AM (#234971) Homepage
    Ah, none other than the Jamie Zawinski (of netscape/Mozilla/Lucid Emacs fame) has been working on this particular problem.

    Check out:
    http://www.dnalounge.com/backstage/log/2001/02.htm l

    Where Jamie provides a pointer to:


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


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

    Check it out here [pwsinc.com] and a Screen Shot is here [pwsinc.com]

    ...and I'm not sure we should trust this Kyle Sagan either.
  • 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.
  • FCGI is basically using C as a CGI scripting language library with additional C support libraries available for doing stuff which is hard in C (such as HTML output functions and text parsing and stuff). it simply replaces perl (and mod_perl) with C (and mod_fcgi). its open source and stuff. check out : http://www.fastcgi.com/docs/faq.html#c_cgi_libs [fastcgi.com]

    for all those here not old enough to remember the birth of the world wide web and scripting languages for generating dynamic html for web servers, perl was NOT the first scripting language or the fastest. C with FastCGI was the first and it blew away everything in terms of speed (near assembly performance over the web, bare metal -- yeah) but like C's in the usual case it was a bitch to develop dynamic web stuff when perl could do it easier (although slower). so everyone switched to perl and the rest is history (ignoring the flames that went on and ppl whining about perl being really slow).

    of course now everyone is switching to java which is even slower but even easier to develop for so history will probably repeat itself again. we already have the java flaming well underway...
  • I find links renderes slightly pages more pretty than lynx too.

    but I keep using lynx because it's classic like that.
  • 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).
  • Your problems with curses are caused by working under Windows with no curses library installed, yes?

  • by cr0sh ( 43134 )
    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 [xbasic.org], 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 [worldcom.com] - Generation Duh!
  • TCL/TK combined with a touch-screen would be perfect for POS applications.
    Has anybody seen a touch-screen work with Linux?
  • Widgets, Buttons, and Pop-Up windows in pretty colors can all be text-based. The UI doesn't need to be G.
  • 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 :)
  • And, some ever helpful links:Turbo Vision For Unix [ibiblio.org] and Turbo Vision [nbci.com]. Two different ports. Judging by their freshmeat entries, I'd go with the second one.
  • 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.
  • 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 :-).

  • by MartinG ( 52587 ) on Wednesday May 09, 2001 @10:42AM (#234985) Homepage Journal
    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....
  • Oh. You mean like Mozilla. ;)

    - - - - -
  • I would like a way to see all comments that have recieved positive moderation, regardless of their actual score.

    - - - - -
  • by micahjd ( 54824 ) <micahjd@users.sourceforge.net> on Wednesday May 09, 2001 @04:05PM (#234988) Homepage
    I wrote this ncurses driver more as a joke, but maybe it would be useful for someone...

    PicoGUI [sourceforge.net] 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.

  • "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 [arachne.cz] 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 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.

    http://freshmeat.net/projects/turbovisionforunix/ [freshmeat.net]
  • ...depending on your system requirements, you might take a look at the Data Access [dataaccess.com] 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)

  • 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 [slashdot.org] (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 [freerepublic.com] 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 [antioffline.com], 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

  • Cost certainly is no issue... a standalone xterm is really no more expensive than a dumb terminal.

    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.


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


  • The O'Reilly minibook Programming with curses (which I used to think was a "Unix-Hater's Handbook"-style thing)

    I think that there's more than enough of that going around without a specific handbook. For reference:

    [lizrd@linuxbox lizrd]$ cd /usr/src/linux
    [lizrd@linuxbox linux]$ grep -r shit * | wc -l
    [lizrd@linuxbox linux]$ grep -r fuck * | wc -l
    [lizrd@linuxbox linux]$ grep -r bastard * | wc -l
    [lizrd@linuxbox linux]$ grep -r damn * | wc -l

    I must confess though that the shit grep produces quite a few results for "Matsushita CD-ROM controller" which isn't exactly cursing.


  • 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.
  • Thanks to everyone for the input. I'll look into the suggestions.

    (Now I just have to figure out why /. thought I was posting anonymously...)
  • 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.

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

  • 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.
  • There are many, many good reasons for offering a Command Line Interface or full-screen textual interface (TUI).

    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.

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

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

    The same thing works in NT 4 and is located in HKEY_CURRENT_USER\Software\Microsoft\Command Processor

  • 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 [viewtouch.com], 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.

  • I really like the CK8.0 Curses Tcl Toolkit [ch-werner.de].

    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.

  • Slightly offtopic, but Microsoft had a system for doing GUI stuff in text: Character Oriented Windows, or COW for short. Imagine the jokes and T-shirts.

    You can't get it, of course. It was never offered as a product, or else it would have had some other name.


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

  • by Master Bait ( 115103 ) on Wednesday May 09, 2001 @10:26AM (#235014) Homepage Journal
    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.


  • by Ronin X ( 121414 ) on Wednesday May 09, 2001 @10:41AM (#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!

  • 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.
  • 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.
  • by mini me ( 132455 ) on Wednesday May 09, 2001 @11:40AM (#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?
  • by mini me ( 132455 ) on Wednesday May 09, 2001 @11:50AM (#235022)
    I just wrote up a comment [slashdot.org] 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!
  • 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.
  • by bellings ( 137948 ) on Wednesday May 09, 2001 @03:52PM (#235024)
    Development time is no issue... it is quicker to design a GUI using a guibuilder than it is to code something in curses.

    The time-consuming part of GUI development is never the amount of time it takes to make the computer draw the pretty pictures you want it to draw. The difficult part is deciding how the information should be laid out on the screen, and how the user is going to interact with that information.

    There are a few reasons that GUI apps often turn out to be so incredibly shitty for data entry or certain POS tasks, and none of them have anything to do with the GUI. First, they're often written by dumb-asses who believe that the difficult part of creating a GUI is is going clickity-click in the visual builder window. Second, they're often written by people who confuse ease-of-learning with ease-of-use, and no desire to learn the factors that go into ease-of-use for a data entry system.

    I have no idea why you'd imagine a GUI system would be any harder or easier to write than a TUI system, when the difficult part has nothing at all to do with actually slapping up the code to do the TUI or GUI part.
  • 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 [peakprogramming.com].

  • 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).
  • by KidSock ( 150684 ) on Wednesday May 09, 2001 @01:06PM (#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 [gnu.org] 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 [cs.mun.ca]
    Linux Journal Artical by ESR [linuxjournal.com]
    Fujitsu ETI Programmers Guide [uni-hannover.de]
    SCO ETI Programming [sco.com]

    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.

  • by Floody ( 153869 ) on Wednesday May 09, 2001 @10:33AM (#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 http://www.s-lang.org/ [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.

  • Don't you think that...

    Developing Attractive non-GUI Apps for Linux

    is better than...

    Developing non-Attractive GUI Apps for Linux

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

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

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

  • Forget your grandfathers' 8086, here's a dusty, late cold-war relic: Raise your hand if you still remember GEOS for the Commodore 64.
  • 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.

  • by cannon_trodder ( 264217 ) on Wednesday May 09, 2001 @12:52PM (#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!

  • by Old.UNIX.Nut ( 306040 ) on Wednesday May 09, 2001 @12:04PM (#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.

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

"Oh my! An `inflammatory attitude' in alt.flame? Never heard of such a thing..." -- Allen Gwinn, allen@sulaco.Sigma.COM