Which Text-Based UI Do You Code With?

JHWH asks: "I've been asked to design and implement a management software system with text based user interface as the replacement of an older one running on AS/400. Despite my attempts towards a web UI, the customer is actually willing to have a text based UI. The main reasons are the need for a very low bandwidth and the ability to run on serial terminals. All this in the 21st century! Host systems will be Linux, the language will be C or C++. I already thought about the use of text based browsers like lynx or links. So now I have to wipe the dust away from my ncurses manual, or can Slashdot suggest something more effective?"

Comments

What's wrong with ncurses?

[Secret Rabbit]

IMO, unless you can give a good reason why you shouldn't use ncurses, use it.

Re:What's wrong with ncurses?

[Brandybuck]

And you don't need an ethernet cable (or sucking up to IT to get a hole through the firewall). All you need to do is plugin a serial cable and you're done. Need to do a remote connection? Ask the user to turn on the modem, or ssh in.

It's not about being the 21st century, it's about not being stupid. Slapping a web server on an embedded system just so you can interface to them is beyond asinine.

Re:What's wrong with ncurses?

[SnarfQuest]

Just write ansi escape sequences to the screen

And you will then discover some of the reasons why you should have used ncurses in the first place:

1. Does the cursor jump to the next line when you hit the 80th column?
2. If you type a character in the lower right corner, does it scroll up the screen?
3. Are they going to bring in some non-ansi terminals and expect you to make them all work?
4. Which subset of the ansi sequences are going to be available? Using xterm, gnome-terminal, putty, ansi.sys, ...? Which version? They all support different subsets/extensions of the "standard", and have different bugs.
5. What other intresting "bugs" in all the possible terminals do you need to work around?

I'd rather use a library that already handles all the crap.

Re:What's wrong with ncurses?

[SenFo]

I'm not sure I agree with you. When I was first learning to develop in C, I went the route of implementing ANSI directly and, in the end, I wished I had known about ncurses. I spent a lot of time designing a UI because I had to essentially write everything from scratch (functions to draw shapes, buttons, etc.), whereas I could have designed it pretty quickly had I used ncurses.

I went the ncurses route on a robotic project I developed a few years back and things were way easier and the end result was much more desirable. I was using code that had been in development and tested for years rather than some fun project I built in my spare time at home.

I highly recommend not reinventing the wheel unless you have a really good reason.

Re:What's wrong with ncurses?

[tomhudson]

And you will then discover some of the reasons why you should have used ncurses in the first place:

1. Does the cursor jump to the next line when you hit the 80th column?

Only if your terminal window is 80 columns wide. Of course, if you want it to no matter what the actual width, just insert a newline at col80 ...

2. If you type a character in the lower right corner, does it scroll up the screen?

Only if you haven't first set the terminal to raw input ...

3. Are they going to bring in some non-ansi terminals and expect you to make them all work?

Just try to find a terminal that doesn't support the standard ansi escape codes ... they may add extra functionality built upon it, but you can safely ignore that by sticking to the base escape codes.

4. Which subset of the ansi sequences are going to be available? Using xterm, gnome-terminal, putty, ansi.sys, ...? Which version? They all support different subsets/extensions of the "standard", and have different bugs.

So just use the bog-standard ansi sequences.

5. What other intresting "bugs" in all the possible terminals do you need to work around?

As I said, by sticking with the standard escape sequences, you don't have to worry about all the "extensions" each different terminal supports. No need to bother with the terminfo database, etc.

Re:What's wrong with ncurses?

[ByTor-2112]

"Try to find a terminal"? They already have terminals, which need to be used. The point of ncurses would be consistency without worrying about what terminal is being used.

To not use a terminal library like ncurses is completely stupid. To make a decent app, you would have to write the same support functions for various ops that ncurses provides already -- and it will likely handle quirks that you aren't even aware of but the almost 15 years of ncurses development have long since accounted for.

The only question to ask is which terminal library to use. Ncurses is widely available and extremely portable, but there are alternatives such as S-Lang.

Most people seem to think that pretty GUIs with clicky buttons and dialog boxes are awesome, but I personally find full text interfaces to be much faster and efficient. Just think about what your brain has to do to switch from typing on a keyboard to moving your hand to a mouse, locating/tracking a mouse cursor with your eyes and coordinating clicking on a button... Even though you or I know that one can simply hit enter or tab to go to the next field, how often do you see people type their name into a login box then grab the mouse to click down in the password field. That is the epitomy of GUI inefficiency that you can avoid with a text UI.

Long live the text interfaces!

Re:What's wrong with ncurses?

[kfg]

I find it interesting that instead of actually commenting on what I said, you go for the "I'm older and wiser don't argue with me" BS.

I did no such fucking thing and I resent the assertion. I was clearly falling back on childish posturing.

Basically, I used my experience, education and what info the guy/gal gave /. to form an opinion. Care to do the same? You know, instead of this childish posturing.

Well, D'oh! See above.

Of course I did so in part because, basically:

. . ."I used my experience, education and what info the guy/gal gave /. to form an opinion. Care to do the same? You know, instead of this childish posturing."

You did no such thing. You presented a subjective feeling on the matter. Since there is nothing factually wrong with your subjective feeling you are welcome to it. There is nothing for me to argue with on a rational basis. I like red; you like blue. I don't condsider you not liking red to be some sort of attack on me personally.

The guy/gal/thing gave no actual information on the needed application at all. He/she/it was being too weirded out by the idea that someone wasn't all hep about his/her/its web based solution when everyone knows that Web 2.0 is where it's at; for everything, all the time. I yanked at his/her/its chain a bit by suggesting that text was a viable text based interface. And it is. Sometimes. But I don't know if it is in his/her/its case; because I haven't a fucking clue what that case is.

And neither do you. But plain text at the console makes you feel like you're looking at a shell script and you don't feel that a shell script is a real application. Well, ok. If that's your thing/hangup/feeling. Coulda been worse; coulda been your My Little Pony collection or something, which still would have been no nevermind to me.

So I acted silly; even to the point of posturing childishly. Quite on purpose. I do that sometimes. It's my subjective feeling and I'm welcome to it. It isn't an attack on your selfworth.

I've got another subjective feeling; he/she/it is the wrong person/thing for the client; but he/she/it might, if he/she/it keeps its mind open and is willing to think about things and consider my suggestion: become the right person in the process of actually doing the job.

And that would be good for he/she/it.

I'll end by restating and expanding my suggestion somewhat:

When presented with a task do not think in terms of a specific language, interface, solution as your first step. First; define the need.

Then find the simplest solution to that need. Don't add complimications until you need to. Otherwise you're just playing with yourself at your employers expense. Not a bad job, but not necesarily ethical; and you might even get caught.

If your employer wants to pay you to watch, or play with him/her/it; and you are a consenting programmer; well, that's no nevermind to me. That's a subjective thing. Work it out between yourselves. Within reasonable limits the subjective feelings of the employer are even one of the objective programming needs to be met. Maybe he can't work unless there are My Little Pony gifs all over his desktop or something.

But I get the impression that does not describe the specific client in question. I'd hazard a guess, based on the meager information available; that the client would cream their/her/his/its jeans if their need could be met with a six line shell script.

Maybe someone should ask 'em if that's the case and clarify the issue.

KFG

what's the problem?

[Anonymous Coward]

Despite my attempts towards a web UI, the customer is actually willing to have a text based UI. The main reasons are the need for a very low bandwidth and the ability to run on serial terminals.

It sounds like the client's needs are thought out and perfectly reasonable. The problem seems to be with the person they've asked to do the job.

Re:what's the problem?

[belmolis]

What's your beef? The guy is asking about the best way to do what his client wants, not opposing it.

Re:what's the problem?

[Arker]

Nonetheless, he also appears to express astonishment, dismay... the comment about what century we're in betrays him. There's absolutely nothing wrong with a text interfaces, in fact quite the contrary.

Re:what's the problem?

[Anonymous Coward]

Exactly. I'm the grandparent poster and I can only see this ending with one outcome (based on a lot of experience). Because the submitter is begrudgingly doing this and feels that the client is asking for the wrong thing (nevermind that they've clearly expressed their reasoning for their requirements), he's going to do a half-assed job and come back with something along the lines of "Well, it would've worked better if you had used a web-based interface." If anyone from the client company is reading this, I'd suggest finding someone else to do the job.

I'd rather have text than web

[Blakey Rat]

Web interfaces suck in so many novel and unique ways. There's the session timeouts. There's the non-interactivity. There's the random bugs on every browser, and the huge mass of compatibility code required to support all of them. Then there's the web app that requires Sun Java and the web app that requires MS Java, both of which run only in IE, and both of which are supposed to run ON THE SAME MACHINE! (I have to deal with that situation once. Royal pain in the rear-end. I don't remember how I solved it, actually...)

If you want a decent UI, don't bother with web-based stuff. Use a product like RealBasic, do it quick and make a CLI to do all the heavy lifting on the back-end.

Re:I'd rather have text than web

[jonabbey]

Then there's the web app that requires Sun Java and the web app that requires MS Java, both of which run only in IE, and both of which are supposed to run ON THE SAME MACHINE! (I have to deal with that situation once. Royal pain in the rear-end. I don't remember how I solved it, actually...)

Ah.. 1997 called, they want their rant back.

Seriously, Java's pretty clean and clear now, and much better than once it was. Especially with Java Web Start.

Does nothing to help the original poster, but there you are.

Re:I'd rather have text than web

[jonabbey]

It 2007, and my browser uses Java 1.4.2 because a basic corporate app won't run on 1.5. You would recognize the company, We're a big Java supporter.

That's one of the things that Java Web Start gives you. You can have several versions of Java installed concurrently, and the JNLP launch file can specify which versions of Java are known to be compatible. If you don't have a compatible version, Java Web Start can even offer to go out and download the appropriate version for you.

We've been deploying our Java app using Java Web Start since the 1.3 days. If your app doesn't support Java Web Start, your developers are doing you a major disservice.

Re:I'd rather have text than web

[stefanlasiewski]

Ah.. 1997 called, they want their rant back.

Did it ever go away?

In 2004, I worked for a 15,000 Fortune 50 company which required Microsoft Java (last updated in 1999?) for the web-based payroll system. There were hundreds of remote offices in this organization, IT support was completely fractured, and it took weeks (sometimes months) for the central IT organization to send out corporate copy of the MS JVM binaries to some remote offices, to the traveling salespeople, etc.. As a result, people were seeking MS JVM binaries anywhere they could find it, including strange watez sites.

Exactly the type of "safe" software you want for your payroll system.

web based with lynx

[lpcustom]

Just for shits and giggles make it web based and force them to use lynx to interface with it.

Re:web based with lynx

[Geoffreyerffoeg]

Oh, come on. Surely you can implement a terminal in JavaScript?

pokey reference

[Inmatarian]

This should get me modded down and/or knocked unconscious from repeated canings to the face or something.

Conio!

Isn't there a linux port of that?

Re:pokey reference

[tomhudson]

why bother with conio (console i/o - a borland c / turbo c library) when you can just write the raw ansi sequences to the screen? They're really easy, and you can even prototype your interface with nothing more than a text editor (vi or notepad) and "playing" it to your terminal ("type 'filename'" in dos, "cat 'filename'" in linux).

http://www.dee.ufcg.edu.br/~rrbrandt/tools/ansi.ht ml ansi escape sequences.

You can clear the screen, home the cursor, more the cursor to specific coordinates, erase to the end of a line, change foreground and background colors, even have web 1.0-style blinking text.

Just remember that you have to send sequences to set your terminal into raw mode if you don't want line-buffered keyboard input.

Python and ncurses would make a good combination

[caseih]

Seems like the bulk of the UI logic would be easier to develop and more error-free if done in python. python could then tie into the C/C++ backend code where necessary. From my casual search of google, python and (n)curses work very well together.

Text based UI is underrated!

[mikeburke]

Compared to web, it has advantages that the original poster enumerated, as well as:

  - support for hotkeys and shortcuts (especially big for manual data entry/call centre users)

  - ability to easily rescale + resize to fit into available screen real estate.

It's simple for a terminal emulator to scale down fonts when the window is resized. Try that with your average GUI or web page.. not to mention component layout issues when dealing with GUIs. This may sound dumb, but it can be a big issue for call centres having to juggle multiple apps but with only one physical screen.

  - simplified deployment (yes, even simpler than web) - no issues with browser versions, plugin conflicts, etc etc.

  - SPEED! Compared with the latency of your average web front-end.

Issues like this really add up to a big difference for apps that are used intensively.

Re:Text based UI is underrated!

[iPaul]

And, if you want to put it on the Web, you can find a Java Applet that does terminal emualation back to your server.

Re:Text based UI is underrated!

[mmogilvi]

Another related text interface benefit is support for essentially unlimited type-ahead (typing in stuff faster then the computer visually responds to it). In GUIs, single windows generally support type-ahead, but it typically does not work if a dialog opens or closes.

SLANG

[goarilla]

somebody in ##slackware on freenode
once recommended me to try using the slang API
instead of (n)curses based on the fact that he bought a ncurses book
and it sucked monkeyballs and programming ncurses is not really intuitive
some of the other fine folk who regularly sit idle in that channel
also said that if it could be done in a Shell script
you could try using shell and dialog which is a ncurses based program btw
this could obviously be a biased opinion from slackers since the pkgtools in slackware http://www.slackware.com/ are written this way
and they have served us fine for many years
and will continue to serve us happily for many more years to come.

anyway good luck

Re:SLANG

[ColaMan]

Is that post of yours poetry? It almost could be, you know.

Re:SLANG

[jbrader]

You are like the e e cummings of ./ posts.

Try Charva

[jpavel]

Charva is an curses-based, Java text UI toolkit that is modeled after Swing. If you know Java and Swing, using Charva is quite straightforward, and won't require you to muck around writing your own text widgets.

Turbo Vision!

[pestilence669]

Borland's Turbo Vision UI was rather nice, considering it was all Text. It's even been ported for GNU toolsets: http://tvision.sourceforge.net/

Screenshot from the link of it on QNX: http://tvision.sourceforge.net/tv2-QNX-tvscreen.jp g

The nice thing about it is that it's OO... one of the very first OO TUI's, if I remember correctly.

I have absolutely no idea how it'll work over a terminal. XTerms an option?

Re:Emacs Trumps

[tomhudson]

The article title has nothing to do with the article contents.

... the title is "Which Text-Based UI Do Yo Code With" - not "Which Text-Based UI Library Do You Write To/Compile Against".

Slang

[John Hasler]

S-lang, possibly with libnewt:

slang1 - The S-Lang programming library - runtime version.
Description: The S-Lang programming library - runtime version
  S-Lang is a C programmer's library that includes routines for the rapid
  development of sophisticated, user friendly, multi-platform applications.

libslang1 - The S-Lang programming library - runtime version
libslang1-dev - The S-Lang programming library, development version
libslang1-pic - The S-Lang programming library, shared library subset kit
libslang1-utf8 - The S-Lang programming library with utf8 support
libslang1-utf8-dev - The S-Lang programming library, development version with utf8 support
libslang1-utf8-pic - The S-Lang programming library, shared library subset with utf8 support
libslang2 - The S-Lang programming library - runtime version
libslang2-dev - The S-Lang programming library, development version
libslang2-pic - The S-Lang programming library, shared library subset kit
libterm-slang-perl - perl interface to the S-Lang terminal library
slang-cfitsio - read and write FITS files from S-Lang
slang-curl - transfer files using HTTP and FTP from S-Lang
slang-gdbm - access to GDBM databases from S-Lang
slang-gsl - GNU Scientific Library binding for S-Lang
slang-gtk - binds the GIMP Toolkit (GTK) to the S-Lang scripting language
slang-histogram - create and manipulate histograms from S-Lang
slang-pvm - PVM (Parallel Virtual Machine) interface for S-Lang
slang-slirp - C code generator for the S-Lang scripting language
slang-tess - regression testing system for the S-Lang scripting language

libnewt0 - Not Erik's Windowing Toolkit - text mode windowing with slang
Description: Not Erik's Windowing Toolkit - text mode windowing with slang
  Newt is a windowing toolkit for text mode built from the slang library.
  It allows color text mode applications to easily use stackable windows,
  push buttons, check boxes, radio buttons, lists, entry fields, labels,
  and displayable text. Scrollbars are supported, and forms may be nested
  to provide extra functionality. This package contains the shared library
  for programs that have been built with newt.

libnewt-dev - Developer's toolkit for newt windowing library
libnewt-perl - Perl bindings for Erik Troan's newt text-mode windowing toolkit
libnewt-pic - Not Erik's Windowing Toolkit, shared library subset kit
libnewt0.52 - Not Erik's Windowing Toolkit - text mode windowing with slang
newt-tcl - A newt module for Tcl
pike7.6-pexts-newt - Pike Newt module
python-newt - A NEWT module for Python
whiptail - Displays user-friendly dialog boxes from shell scripts

Re:omg

[ralphdaugherty]

...a management software system with text based user interface as the replacement of an older one running on AS/400. Despite my attempts towards a web UI, the customer is actually willing to have a text based UI. The main reasons are the need for a very low bandwidth and the ability to run on serial terminals. All this in the 21st century! Host systems will be Linux, the language will be C or C++.

      I'm an AS/400 guy, used to be a PC programmer. I'm trying to understand this, any comments appreciated. What's clear to me is the company is converting from an AS/400 to Linux (yes, Linux runs concurrently in partitions on the AS/400, now called system i after several name changes, but I'm also assuming they want a cheap Linux server).

      I remember in some early programming (I was original programmer for Melita Electronics, later International, they did well :) hooking Wyse serial terminals to a PC and controlling multiple terminals from a PC with a multi-serial port board.

      The AS/400 of course has not had serial terminals, they have 5250 terminals or PC terminal emulators over TCP/IP now, IBM networking before that. So I take it this serial port thing is a throwback to what I used to do because this company says, we have a Linux PC server, let's hook up cheap serial port terminals? With serial communications limitations and dirt cheap PC's able to run any kind of terminal emulation cheaply, something very strange about that to me.

      The best I can tell from this is the purpose of NCURSES would be to emulate 5250 PC emulation with a serial port terminal emulator. But like I say, any clarifying comments welcome.

      The replacing a "management software system" equivalent to what they had on the AS/400 in C++ on Linux would seem to be quite a job in itself. All of the work that NCURSES does is taken care of by our 5250 I/O subsystem. That's quite a lot of I/O detail that he will have to insert into the replacement.

      By the way, NCURSES doc says it runs on any POSIX platform, and the AS/400 (which is usually called iseries now) has a C++ compiler and is POSIX compliant. The C++ modules can be bound together with modules from any other language on the iseries into an i5/OS program.

      It could communicate with anything over TCP/IP, but I would have to check if we can rig up serial ports for terminals. :)

  rd

Re:What's wrong with text screen GUIs?

[scdeimos]

DesqView, PCtools for DOS.

Except that it sounds like the client (probably a bank or a lotto agency) already has a considerable investment in serial terminals, so no DOS for you: The main reasons are the need for a very low bandwidth and the ability to run on serial terminals.

Re:Something you might look into

[kbob88]

I agree: Ruby + ncurses for the UI, calling C/C++ modules to do whatever heavy lifting you need (if any).

There's no reason in this day and age to write a non-performance-sensitive UI in C or C++! Especially a text based one. Why would you go through such hell for a task that doesn't require optimal performance? Seriously: you can learn Ruby and code the UI in less time than it will take you to code it in C or C++. I guarantee it. Plus it will be a lot more fun. And you can link in C and C++ modules to execute any performance-sensitive tasks.

Unless there's some reason your text-based UI needs optimal performance, but I can't think of one offhand... I've sworn off all C/C++ development unless there's an overwhelming reason to use them. Heck, I don't even use Java much any more -- it's mostly all Python and Ruby, with an occasional module in C/C++ for performance.

You should be able to whip out a text-based interface using these tools in no time, even if you've never used Ruby. Like tonight. Or maybe over the weekend.

And no, I'm not some Ruby fanboy. I've got over 20 years professional programming experience, plus another 8 years non-professional. I've used many languages over that time. It's all about the right tool for the job. Python would be another great choice (perhaps even better because of its more extensive libraries). But C and C++ are definitely not the best tools for the job. (Unless there's something you haven't shared with us.)

64bit browser plugin

[Builder]

1997 can have its rant back when someone tells me how to run java apps inside firefox on a 64bit machine. Installing 32bit firefox on 64bit FC5 is more grief than I ever thought would be possible, and Sun don't have a mozilla plugin for 64bit Linux.

Web application vs Java Webstart

[dna_(c)(tm)(r)]

A web application that depends on Java in the browser probably uses applets. That is not the best way to solve any problem since there are dependencies out of the programmers control (versions of Java on the client, browser problems,...), it is similar to a (windows only) ActiveX dependency.

Java Webstart is very different, it handles deploying Java Applications (typically Swing UI based impementations, nothing to do with Applets or JApplets), resolves Java version dependencies etc. Webstart uses any Java version since 1.3 and any browser to download the initial jnlp file (the launch file, an xml file containing download, security and configuration data) and start the javaws process. The application runs outside the browser context, stand alone.

If you still use 1997 technology (applets) then you're probably encountering the 1997's problems. Knowledge has evolved since those days.

Re:Emacs!

[JabberWokky]

Didn't the Amazon order system run for quite awhile on Emacs? Here's a note about it, but the main article has gone 404.

--
Evan

Re:Emacs!

[socalian45678]

Steve Yegge moved it here: http://steve.yegge.googlepages.com/tour-de-babel