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?

[poopie]

Yeah, ncurses is where you should start. Download the source distribution and look at their numerous examples for inspiration.

Oh, and I don't think it's dumb to want a console app instead of a web app. Console apps can run *QUICKLY* on any old system of just about any OS or architecture with any speed CPU with any amount of RAM with any amount of bandwidth.

Re:What's wrong with ncurses?

[jonabbey]

Yeah, I'll third that. ncurses is completely A-OK for terminal apps to be deployed on Unix-style systems. Especially since you're wanting support for serial consoles.

In point of fact, I'm not familiar with any new advances in terminal display libraries since ncurses, really. I know that Red Hat uses a Python-based installer (Anaconda) that can support both a graphical/X display and a text-mode interface when no X display is available. It may be interesting to see what they are using, as I suspect they are using a higher level windowing library that has curses and X display options. If you are Python-friendly, it might be worth looking at that to see if they're doing anything usefully fancy.

Otherwise, yeah, ncurses is what I've got.

Re:What's wrong with ncurses?

[tomhudson]

Just write ansi escape sequences to the screen, same as back in the good ole days of writing bbs software.

1. A lot less complex than using ncurses.
2. portable between linux/bsd/windows
3. runs nicely over even a dial-up connection
4. you get to dust off your ansi artwork
5. no worry about runtime dependancies or unavailable libraries

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?

[kfg]

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

I'm afraid I look at things from the other end and say you shouldn't use ncurses unless you can give a good reason for it.

My favorite text based UI is, wait for it, wait for it. . .

Text!

KFG

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?

[Secret Rabbit]

Well, he did ask for a text based UI. Just using stdout isn't exactly what I would call a text based UI.

For that matter, since the people (s)he's developing for are moving from a AS/400. So, they're probably used to something like ncurses.

Also, personally when I see scrolling text, I think of config scripts and the like. But, something like ncurses gives me the feel of an actual application (not to mention *far* more control over the output i.e. highlighting, colours, etc). I honestly think that there is a reason for this given that I've lived in terminals for most of my computer experience. That reason, IMO, being a long the lines of an unspoken standard.

Re:What's wrong with ncurses?

[EvanED]

I did a neat little project with ncurses for a class as an undergrad. It was mostly an excuse to learn curses, but it was a neat little program that would send HTTP requests you could define and display the response. (Sort of like a telnet, but without the free-form "type anything" aspect of it.) I ended up writing some widget classes, like text boxes or checkboxes, that worked somewhat like what you'd see in a GUI toolkit. There were a couple projects along that line already, but it was sort of a fun exercise to do ourselves.

Re:What's wrong with ncurses?

[kfg]

Just using stdout isn't exactly what I would call a text based UI.

Well I wouldn't call it bunny rabbits, that would be silly.

Also, personally when I see scrolling text, I think of config scripts and the like. But, something like ncurses gives me the feel of an actual application. . .

Watch youself, Sonny, before I go into a spiel about how kids these days don't know the special joy of being able to read output directly from the little holes punched in the paper tape.

KFG

Re:What's wrong with ncurses?

[iangoldby]

My favourite text-based interface:

#include <stdlib.h>
#include <stdio.h>
#include "getopt.h"
 
int main(int argc, char *argv[])
{
  extern char *optarg;
  extern int optind;
  int opt;
  unsigned int i;
  static struct option longopts[] =
  {
    { "help", no_argument, NULL, '?' },
    { "version", no_argument, NULL, '\x80' },
    { 0, 0, 0, 0 }
  };
 
/* Get options */
  while ((opt = getopt_long(argc, argv, "?", longopts, NULL)) != -1)
  {
    switch (opt)
    {
    case '\x80': /* Print version number */
      version(stdout);
      exit(EXIT_SUCCESS);
      break;
    case '?': /* help */
      usage(stdout);
      exit(EXIT_SUCCESS);
      break;
    }
  }
 
  for (i = optind; i < argc; i++)
  {
/* Do stuff with argv[i] */
  }
 
  exit(EXIT_SUCCESS);
}

This isn't a completely facicious suggestion. If you have a suitable shell, why not let it do some of the work?

Re:What's wrong with ncurses?

[TheSHAD0W]

I'm maintaining a curses version of an application and get lots of problem reports where curses gets into a bad state and ceases to function properly, and this is despite trying to shut down and reinitialize the library. If you can standardize on an ANSI terminal implementation, and use just the basic commands so as not to run into compatibility issues, I recommend you implement ANSI directly.

Re:What's wrong with ncurses?

[SenFo]

That's all and well for software that you expect to process a request and then return to the shell; however, I don't exactly think his users would find it to be very user friendly for, say an accounting application.

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?

[tchuladdiass]

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

Actually, some terminals will leave the cursor at column 80, and only advance to the next line after another character is output; others will put the cursor at column 1 of the next line immediately after a character is placed at column 80. Why does this matter? Well, if you output a character on column 79, then a cr/lf, you'll get the next output at the beginning of the next line, where you expect it. But if the last output was at column 80, then followed by a cr/lf, then some more text, on some terminals you'll get an extra blank line inbetween (the second case), and other terminals will not (the first case).

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

This has more to do with if the terminal performs an automatic cr/lf after a character is placed in column 80 (see previous point). The "raw" output you're probably thinking of is yet another layer, but that is actually in the host's tty driver (stty settings), and is independant of the terminal itself.

Just try to find a terminal that doesn't support the standard ansi escape codes

Many terminals only supported their native escape sequence set, up until the last 10 years or so. But chances are that there are very few of those left in service. There are, however, certain functions that a lot of terminals supported that aren't in the ANSI list, such as "screen protect". This is a mode where you can define some of the text on screen as "protected" (this would usually be components of an input form); when a "clear screen" is issued, the "protected" components would remain on screen so you can easily clear the form data without having to redraw the form itself. Televideo and I believe Wyse terminals are a couple examples of this.

So just use the bog-standard ansi sequences...
...by sticking with the standard escape sequences, you don't have to worry about all the "extensions" each different terminal supports

The wonderful thing about standards is that there are many to choose from, and even more ways to interpret them. The largest problem you'll run across is what was mentioned in points 1 and 2 above, how the terminal handels scrolling after a character is placed in the last column. If you get a chance, take a look at the book "termcap and terminfo" from o'reilly. It's got a bunch of other odd ball items that one wouldn't even dream about. But even if you still want to avoid using curses in it's entirety, there's several functions that are defined in the curses library for grabbing various items out of termcap / terminfo, such as the "bugs" for each terminal type and escape sequences for the various cursor positioning commands. And, since you're likely to define a number of string variabls / functions such as "clear_screen" and "move_cursor", you might as well use the already-written tools that handle this for you -- even if you aren't using any of the UI elements from curses.

Re:What's wrong with ncurses?

[irc.goatse.cx troll]

It's also a lot harder to modify or fix when you want to change something. Admittedly my only experience with extensive raw ansi stuff is through bash, so I'm sure thats part of it.

http://catheadlabs.com/semi/menu.txt if anyones curious for an example. This was back when brained.org was still around, for anyone that remembers those days. I think theres a few raw escapes in there so watch out for them if you copy/paste.

Re:What's wrong with ncurses?

[cyclop]

What I would really drool for would be a ncurses port of WxWidgets.

I have confused memories someone tried it, but the project died. It would happily unite console and graphic programming.

Re:What's wrong with ncurses?

[ralphdaugherty]

They already have terminals, which need to be used.

      That's an amazingly bad assumption. They have an AS/400 which in this day talks to PC's running a 5250 terminal emulation program.

      The fact that the company wants to use serial terminals is only an indication they want to go as cheap a route as possible. A post or two in this thread jumped on a "they have serial port terminals to use" thing because any other possibility is sort of stupid.

      But it is what it is.

  rd

Re:What's wrong with ncurses?

[Secret Rabbit]

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.

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.

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

Re:What's wrong with ncurses?

[jgrahn]

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

You forgot the best reason: ncurses will optimize your I/O for you. "Is there already an 'a' at (10, 15)? Then don't render it again".

Re:What's wrong with ncurses?

[fyngyrz]

I'm maintaining a curses version of an application and get lots of problem reports where curses gets into a bad state and ceases to function properly

I was reading the thread and shaking my head in amazement until I read your comment. This has been my experience as well -- ncurses is FULL of bugs; a good number of the demos they provided crashed, others didn't do what they were supposed to in the first place. Working with linux terminal configurations is an exercise closely akin to re-imagining voodoo from the start, and versions talking between different operating systems don't work right either, even with the simplest of sequences. Tools depending on ncurses like midnight commander work properly on most linux machines but not on a mac... the list goes on and on. After evaluating curses, I totally trashed the idea of ever using it. I needed something that actually worked. All the time. Across the maximum number of terminal environments. ANSII is indeed the answer.

I had a fairly complex system to write, about 4 megs of C-compiled executable in the end not counting the text control code, had to be text, needed just about everything you can imagine in terms of widgets - menus, drop downs, fairly extensive use of color, text fields, input validation before echo, lists, scrolling columnar subsystems... all this is talking to a big database that does inventory management, 100% live inventory for the website, mailing, UPS and Fedex and Post, box pre-pack estimation, all of which is in the app. Did I *want* to write a text system as well? Hell, no. But ncurses is shite.

So I wrote it. Took a few months, but now I have a system that uses cursor positioning, in-memory layered windowing that is updated to the terminal, never gets out of sync and works with *anything* that uses ANSI across any linux or PC OS. All this silliness about what the cursor does at the end of the line is obviated by reasonable interface design and a little careful cursor positioning. These aren't tough problems, and I can't believe otherwise sophisticated programmers that haunt slashdot would consider them so.

Would I have used curses/ncurses if it worked? Sure. In a heartbeat. Would have saved me a lot of work. But the fact is, for serious projects, it isn't very usable. If I have to debug code, I'd rather debug my own.

The final product runs 100% on Amigas, PC's, Linux, OSX, my flipping *palm pilot*, and my ca. 1970's 6809 Flex system running a terminal emulator. That's what I'm talking about. It "just works." It runs through SSH for remote use or telnet if security isn't an issue, such as fully in-house networking. It's even reasonably pretty, considering its a text interface.

Re:What's wrong with ncurses?

[TheSHAD0W]

I don't suppose you could open-source your library? ^__^

Re:What's wrong with ncurses?

[fyngyrz]

Actually, I could. I kept all the rights. I'd have to think about it.

Re:What's wrong with ncurses?

[tomhudson]

Their terminals will work just fine with ansi escape codes - wtf do you thing ncurses sends it? Magic pixie dust?

Using ncurses when you don't need to is dumb. Adding complexity for the sake of complexity doesn't make sense.

Avoiding ncurses means avoiding event loops, callbacks, etc.

Or have you ever even used it? Because from your post, its obvious you don't know much about when it comes to terminals.

I've written terminal apps (with their own serial-port drivers), and it was easy to write my own screen-handling routines. Any half-competent c programmer should be able to do the same.

Re:What's wrong with ncurses?

[tomhudson]

You don't need to use extended features like "screen protect" - have your app figure out how to update the screen accordingly and you're good, and you now have "screen protect" for all terminals.

Even a 20-year-old green-screen terminal works fine with plain ansi sequences - I know, I've had to use them (the company would buy old ones by the palette for $25 and put them into service as units died out. At $1 - $2/terminal, it wasn't worth the hassle of buying new ones).

You'd set it into raw input on the client side, obviousy - but you can do that by issuing the proper escape sequences in a script.

There's also a ton of code around for doing tty form handling utside of ncurses. try typing "dialog" at the command prompt. It creates dialog boxes to be displayed from shell scripts.

Sample code: dialog --msgbox "hello, world!" 5 40

If you want to see the output, type : dialog --msgbox "hello, world!" 5 40 > output.txt

You'll have to press enter twice (the console is waiting for your input).

Then use any editor to see the output - a bunch of ansi escape sequences:

^[[?1049h^[[1;45r^[(B^[[m^[[4l^[[?7h^[[?1h^[=^[[?1 000h^[[39;49m^[[?1h^[=^[[39;49m^[(B^[[m^[[H^[[2J^[ [26d^[(B^[[0;1m^[[36m^[[44m^[[J^[[H^[[K ^[[K ^[[K ^[[K ^[[K ^[[K ^[[K ^[[K ^[[K ^[[K ^[[K ^[[K ^[[K ^[[K ^[[K ^[[K ^[[K ^[[K ^[[K^[[20;48H^[[1K ^[(0^[[0;1m^[[37m^[[47mlqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqq^[(0^[[0m^[[30m^[[47mk^[(B^[[0;1m^[[36 m^[[44m^[[K^[[21;48H^[[1K ^[(0^[[0;1m^[[37m^[[47mx^[(B^[[0m^[[30m^[[47m hello world^[[26X^[[21;88H^[(0^[[0m^[[30m^[[47mx^[(B^[[0 m^[[30m^[[40m ^[(B^[[0;1m^[[36m^[[44m^[[K^[[22;48H^[[1K ^[(0^[[0;1m^[[37m^[[47mtqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqq^[(0^[[0m^[[30m^[[47mu^[(B^[[0m^[[30m^ [[40m ^[(B^[[0;1m^[[36m^[[44m^[[K^[[23;48H^[[1K ^[(0^[[0;1m^[[37m^[[47mx^[(B^[[0m^[[30m^[[47m^[[15 X^[[23;65H^[(B^[[0;1m^[[37m^[[44m^[(B^[[0m^[[30m^[ [47m^[[15X^[[23;88H^[(0^[[0m^[[30m^[[47mx^[(B^[[0m ^[[30m^[[40m ^[(B^[[0;1m^[[36m^[[44m^[[K^[[24;48H^[[1K ^[(0^[[0;1m^[[37m^[[47mm^[(0^[[0m^[[30m^[[47mqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj^[(B^[[0m^[[30m^ [[40m ^[(B^[[0;1m^[[36m^[[44m^[[K^[[25;50H^[[1K ^[(B^[[0m^[[30m^[[40m^[[40X^[[25;91H^[(B^[[0;1m^[[ 36m^[[44m^[[K^[[23;68H^[[39;49m^[(B^[[m^[[45;139H^ [[?1000l^[[45;1H^[[?1049l^M^[[?1l^[>

Re:What's wrong with ncurses?

[Tore S B]

"Those who don't know ncurses are doomed to reinvent it, badly."

Seriously, though. Your arguments make no sense.

Using ncurses when you don't need to is dumb.

Yes, of course, but it's fairly clear that this is the ideal use case for ncurses.

Adding complexity for the sake of complexity doesn't make sense.

Again, does not apply. ncurses is actually quite elegant, and well thought-out. It's adding complexity for the sake of portability across terminals, speed (ncurses optimizes escape codes far better than most programmers who do it by hand), and abstraction (a lot of the terminals in the field aren't ANSI.)

Avoiding ncurses means avoiding event loops, callbacks, etc.

Yes, and this is a good thing how?

Or have you ever even used it?

Well, I have, a lot, and I've found it to be more than worth it. It's a well-thought out, 15-year-old library which is the swiss army knife of console TUIs. It's the standard library for a reason!

Re:What's wrong with ncurses?

[ByTor-2112]

Yes, actually, I have used ncurses extensively in the past. How kind of you to assume otherwise. I found it to be a wonderful abstraction layer to send the funky escape sequences for me rather than trying to figure them out on my own. And since you are going the route of insults, I would have to say that you appear to be quite the idiot to me, and I wonder if you know the first thing about proper curses development. I'd bet dollars to donuts that whatever garbage code you put out wasn't half as efficient in bandwidth and code speed as a similar curses application. But that's just my opinion!

No need to respond, because I won't be reading it.

Re:What's wrong with ncurses?

[ByTor-2112]

TFA said:

The main reasons are the need for a very low bandwidth and the ability to run on serial terminals.

Which I would interpret as "run on serial terminals that we already have".

They have an AS/400 which in this day talks to PC's running a 5250 terminal emulation program.

I would characterize that as the amazingly bad assumption, rather.

Re:What's wrong with ncurses?

[tomhudson]

"Those who don't know ncurses are doomed to reinvent it, badly."

unlike you, I've used ncurses. It isn't needed in many cases, and is not just overkill, but the wrong tool for the job.

Using ncurses when you don't need to is dumb.

Yes, of course, but it's fairly clear that this is the ideal use case for ncurses.

Quite the contrary, it isn't clear at all. Do you have the design specs? The use cases? The different modes of operation? Didn't think so.

Adding complexity for the sake of complexity doesn't make sense.

Again, does not apply. ncurses is actually quite elegant, and well thought-out. It's adding complexity for the sake of portability across terminals, speed (ncurses optimizes escape codes far better than most programmers who do it by hand), and abstraction (a lot of the terminals in the field aren't ANSI.)

Ncurses is butt-ugly. and btw, while a lot of terminals aren't just "ansi", they speak ansi. Also, even totally unoptimized ansi runs fine on 19.2k multi-port serial connections.

Avoiding ncurses means avoiding event loops, callbacks, etc.

Yes, and this is a good thing how?

Clearer operating modes, fewer bugs. That's always a good thing.

Re:What's wrong with ncurses?

[tomhudson]

You wrote:

And since you are going the route of insults, I would have to say that you appear to be quite the idiot to me,

However, you seem to forget that you're the one who started with the insults when you wrote this:

To not use a terminal library like ncurses is completely stupid.

... in response to my suggestion not to use ncurses.

I guess that the +5 Interesting means a lot of us are stooopid because we don't automatically assume that ncurses is the "only solution".

Ncurses may be the "swiss army knife" of text-mode interfaces, but not every job calls for a swiss army knife. The K.I.S.S. formula works fine for many of us. I'd rather cut my steak with a single-purpose steak knife than a swiss army knife. Similarly, automatically assuming that ncurses is the best/only realistic option is simplistic.

found it to be a wonderful abstraction layer to send the funky escape sequences for me rather than trying to figure them out on my own.

??? WTF? The ansi escape sequences can be "learned" in 10 minutes. They're really, really simple. Simple as in "you can do it with just a text editor, and then cat the file to the screen and see the results." No compiling. No executable files. Simpler than html, in fact. If you couldn't take 10 minutes to figure them out, that says more about you than about which tool is right for the job ...

Re:What's wrong with ncurses?

[Tore S B]

unlike you, I've used ncurses. It isn't needed in many cases, and is not just overkill, but the wrong tool for the job. Firstly, I've used it for years, and like countless others I am very happy about it. Your assumption is quite frankly stupid. I've used it going back to 4.3BSD on a VAX 6000, and with a range of real terminals, from Tandberg (Really, really excellent terminals!), Facit, DEC (of course), and HP. Secondly, I find you saying that it's not the right tool for the job highly ironic considering your next statement:

Quite the contrary, it isn't clear at all. Do you have the design specs? The use cases? The different modes of operation? Didn't think so. It was summarized in the question. Low bandwidth use was a critical feature, on an IBM system which is likely to use terminals which brings me to the next item...

Ncurses is butt-ugly. and btw, while a lot of terminals aren't just "ansi", they speak ansi. ...a *lot* of IBM terminals do not. Sure, you have the ones like the 3151, and such - but they're often the exception. Secondly, a lot of terminals have their quirks and optimizations which ncurses will automagically compensate for. I've written a torture test that will almost always fail.

Also, even totally unoptimized ansi runs fine on 19.2k multi-port serial connections. Firstly, old terminals usually have to do XON/XOFF when encountering escape codes because of the microprocessor needing to run the codes themselves. I have a high-end serial console which cost as much as a (okay, Soviet import, but.. :) car in the day. It will occasionally have to pause output, even at 4800 which I run it at. Secondly, the bandwidth is stated to be severely limited.

Clearer operating modes, fewer bugs. That's always a good thing. Are you saying that throwing away a widely adopted, 15-year-old time-proven library to do ones own implementation of basically exactly what ncurses does... causes less bugs?

Re:What's wrong with ncurses?

[ralphdaugherty]

The main reasons are the need for a very low bandwidth and the ability to run on serial terminals.

Which I would interpret as "run on serial terminals that we already have".

      That's the amazingly bad assumption, or bad interpretation if you prefer. As I said, you weren't the only one to assume that. It's hard to envision what the company IT management is thinking otherwise.

They have an AS/400 which in this day talks to PC's running a 5250 terminal emulation program.

I would characterize that as the amazingly bad assumption, rather.

      5250 terminals are not serial port terminals. That's why an AS/400 shop saying they want to convert to Linux with serial port terminals is not leveraging any AS/400 terminals they had before.

      Of course, if they had PC's running 5250 emulation they can use the PC's to run serial terminal emulation. It is clear to me the cheapness they seek is not in reusing hardware, it is the simplicity of the protocol and administration.

      In any event, there is no AS/400 hardware to leverage to non-AS/400 Linux and serial port terminals, so not an assumption on my part, amazingly bad or otherwise. :)

  rd

Re:What's wrong with ncurses?

[tomhudson]

All I'm saying is that without enough information, why not look at ALL the possibilities? Since the poster was an "ask slashdot", and indicated that they originally wanted to do this as a web app that could be accessed through links/lynx to accomodate the "low bandwidth" scenario, and that was nixed, we can't assume much in the way of writing code for environments outside of the web ... maybe little or no c/c++, for example - but their first hurdle may be the server, not the client.

We can't even assume they're using multi-port serial cards ... or terminals. So lets make a few assumptions - that they're going to be running this on a beige box, that they're in fact using a multi-port serial breakout box, and that the clients are either smart terminals or pcs running a terminal emulator.

"bandwidth-constrained" today doesn't mean the same as "bandwidth-constrained" a couple of decades ago. Without knowing what the requirements are, its impossible to say if ncurses is the best way to go.

As for the terminals themselves, one of the places I worked at just bought them used by the pallette for $25, and they all "spoke ansi". Places were throwing them in the dumpster because nobody wanted them.

As for the speed of the microprocessor, if they're still stuck with the green screens, they would probably be better off picking up a few junk laptops and using them as their "smart terminals". Any old 286, 386 or 486 would do - you can find used 486s for next to nothing. They won't even need a hard drive or battery - just power them up from a wall wart, boot them off a floppy or cd and run the terminal software from the same media.

After all, how much can a used laptop with a bad hard drive and no battery cost?

The best part - they'll have a serial port on the back that's good for 33.6 (and if its at least a 486, probably up to 115k, though I've had trouble with long cable runs at anything over 33.6).

One sequence of events:

1. server sends client a screen with fields to fill in, etc.
2. at every keypress, client sends keypress back to server to be processed
3. server processes keypress, sends back screen updates

The end result will be slow and ugly.

If some smarts are embedded in the client program (the screens, the local key handling, cursor control, etc) ...

1. Client software generates screen
2. User inputs data - client software does all screen handling
3. On completion, client software sends data to server, and waits for response codes
4. goto 1

A lot less traffic between the client and server, and screen control is handled completely locally. Of course, this means running the client on a pc, not a terminal ...

Without enough info, we can't make a rational decision, so we should consider all the possibilities ...

Re:What's wrong with ncurses?

[Tore S B]

You're changing the subject. The potential sacrifice in bandwidth was a very small sidepoint compared to the relative merits of rolling your own ncurses-alike and using ncurses itself - even though I'd expect ncurses to be able to optimize far better than most programmers could (or even should), using general functions.

Re:What's wrong with ncurses?

[tomhudson]

Changing the subject? The article was asking the best way to build a text-beased ui app. Not enough info is given (type of data presented to user, range of responses required from user, deployment, hardware, user base, server options, etc.) for anyone to be able to state "ncurses is THE solution."

Heck, for all we know, they're using dumb terminals that have zero cursor control - you have to draw the screen strictly a line at a time, wait for the user to respond, then scroll everything out of the way and start over.

Ncurses isn't necessarily the right tool, but only the person who originally posted the question is in a position to decide whether they want/need ncurses. Using ansi escape sequences might be the best scenario. I'm not saying it is, but that it should be considered, instead of just "ncurses is the one true way", because it quite simply isn't.

Its the same with java - I've always made fun of its slowness, wordiness, bloatedness, etc., but I'm still recommending we use it at work for one particular application where neither c nor a scripting language are appropriate.

Something to think about ...?

Re:What's wrong with ncurses?

[Tore S B]

You're inconsistent, self-contradictory and wrong. I guess that's what you get when arguing on slashdot.

Re:What's wrong with ncurses?

[tomhudson]

I am neither inconsistent nor self-contradictory. As to the "wrongness" of my argument that ncurses is not necessarily the best solution, as I pointed out, the only person who is in a position to decide that is the person who posted the original question. Or are you now claiming to be psychic?

Not using ncurses does NOT mean doing a "roll-your-own" reimplementation of ncurses, unless the person who posted the original question needs all the ncurses functionality. They were asking for various ideas - you like ncurses, fine. In certain circumstances, I'd agree. However, this is not one of them, for the simple reason, as I have pointed out, that we do not know the circumstances. If you can't see that, then that's your problem, not mine.

Whether ncurses is or is not a mess is totally beside the point - which was to consider various solutions. Ansi escape codes for terminal display handling are quick and easy to implement, and have the side benefit that the pages can be stored in plain text files, or as varchar fields in a database, they can be edited with any plain-text editor, there is no need to recompile the application if you're changing the display, you can make a templating system easily using regexes, etc...

Ncurses when necessary, but not necessarily ncurses. K.I.S.S. is still a good idea.

Re:What's wrong with ncurses?

[Tore S B]

You're calling ncurses dirty but you're saying you could store terminal escape codes in a varchar?!

Re:What's wrong with ncurses?

[tomhudson]

If you're using a templating system and regexes (as I suggested :-), you don't actually store the escape codes, just a mnemonic for them.

For example, [CUP] for cursor up, [HOME] for home the cursor, [CLEOL] for clear to end of line, [10,15] to go to row 10, column 15, etc. Heck, you could implement all of ncurse's features that way ...

Not only is this easier for the end user to edit/maintain, but again, it can be done in a plain-text file, or stored in a db.

It would also make it fairly easy to develop an alternate web interface to everything, not just for maintenance, but also for those users who aren't constrained by bandwidth and/or hardware limitations.

Heck, with a bit of javascript, some css, and a bit of ajax (without the xml), you could also emulate a terminal right in the browser ... and if that's the case, then the bandwidth usage is the same (after the initial page load - and even that can be obviated by using a proxy locally to load a local copy of the page, then proxy the data from the server).

I think its the sort of thing that would actually be fun to do. And it would sure beat those "screen-scraper" interfaces (if you've seen one, you know how ugly they are).

Re:What's wrong with ncurses?

[Secret Rabbit]

Sir, you embarrass yourself and I fully believe that you don't realize this. I for one, b/c of the above, will no longer reply to any of your posts.

Good day.

Re:What's wrong with ncurses?

[Anonymous Coward]

And a good choice that is indeed. He is older and wiser than you, and he'd probably humble you again.

Re:What's wrong with ncurses?

[CandyMan]

The only embarrassment is in leaving out a closing tag for , for the rest of the comment he made total sense. Being shocked that someone thinks a stdout interface is what will get the job done (when a full-screen ncurses-like interface is where it's at, of course!) neatly parallells being shocked that someone thinks any text interface will get the job done (when a web 2.0 app is where it's at, of course!).

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.

Re:what's the problem?

[DerekLyons]

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.

Yup, the writer of TFA displays IT/techie zealotry and elitism at it's very finest. It's interesting that right near this story on the front page at the moment is this story which ends with the question "Should software 'just work', or are users too lazy?".

Ncurses it is.

[liftphreaker]

Curses does the job. It may not be the most elegant solution, but it does it. I see no reason why you shouldn't use it. Curses has been around for donkeys years and it works.

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

[clem.dickey]

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.

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.

Re:I'd rather have text than web

[Brandybuck]

It still doesn't change the fact that you frequently run across webapps that require a specific brand/version of Java. One app needs Java 1.5, so you go install it. Another needs Java 1.4 (and refuses to even let you see the login page until you downgrade). The branding isn't as critical anymore, but as recently as last summer I was using a webapp that refused to cooperate with any Sun Java.

Out here in the real world, 1997 hasn't gone away.

Re:I'd rather have text than web

[Anonymous Coward]

This is what I keep hearing, and yet every Java application I use is just as clunky and slow as I remember them being 3 years ago. Maybe it's the application itself (it's possible to write a slow application in any language), but it certainly seems like it's Java's fault considering every application is slow and clunky..

Re:I'd rather have text than web

[Scoldog]

Actually, I can vouch for text based over web based designs, as I have similar problems at my company that BlakeyRat had seen

1. Horrible web based communications program (industry standard, not controlled by my company) which requires both Microsoft VM (Java) and Sun Java to run (don't ask how this is possible, I have no idea). When Sun sued Microsoft, I gleefully told the people running the site that they'll have to update the site to use Sun Java only.

Their response?

"You can still download Microsoft VM from our site".

We finally went live on a new website last week. I'm not bashing Java, the new site is more stable, but slower that the last one. On the flip side, I can initiate a ftp connection via dos to the remote site and transfer stuff a lot quicker than the website

2. Rather painful IE based GUI front end for our telnet based sales system (again, industry standard) that uses a ActiveX control to run. Loves to time out, has not worked properly since it was implemented in October of 2005. The new version gets rolled out next month with more of the text based users being forced onto GUI based.

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.

Re:I'd rather have text than web

[Anonymous Coward]

Text interfaces suck because sometimes my bakc^H^Hck key does not work or color is not available and I cannot use my mouse to go up or down and I cannot render some graphics to visualize things.

Or perhaps you meant to say badly-designed web interfaces suck and I should say badly-designed text interfaces suck ?

Seriously. Why should a web session necesarilly timeout if the user still has the page open ? What do you mean with non-interactivity ? And browser bugs and compatibility code has been taken care of, a hundreds of times, by numerous so-called frameworks.

You might want to update your head with new information: take a look at the Wt library (http://www.sf.net/) which handles all of your complaints.

Re:I'd rather have text than web

[Blakey Rat]

Or perhaps you meant to say badly-designed web interfaces suck and I should say badly-designed text interfaces suck ?

Fair enough. The fact remains that most of the text-based UIs I've used are actually usable and easy to install where most of the webapps I've used either:

1) Are incompatible with another webapp that needs to run on the same browser. (The Sun vs. MS Java problem mentioned above, for instance, or conflicting browser settings.)

2) Requires me to turn off EVERY SINGLE SECURITY FEATURE the browser has. I love the webapps that have 5 pages of "installation instructions" which basically sum up to "go into Internet Options and turn every security feature to low or off."

3) Has sessions that time-out remarkably quickly, considering the amount of data that's supposed to be entered on the form. Yes, there are ways around there. No, most webapps (from my experience) don't use them and instead just set a timeout of around 5 minutes.

4) Are completely un-interactive, requiring a page load for every single submitted field. Try entering a bunch of records into a typical webapp... waiting for page reloads alone is enough to drive you crazy.

For every one Gmail, there's a dozen webapps that suck to high heaven and are sold as golden panaceas to resolve all your problems by huge corporations that should know better, such as IBM. In reality, all they do is add another layer of abstraction to your problems.

Re:I'd rather have text than web

[DaveV1.0]

You can have several versions of Java installed concurrently

While you can do such a thing, it should never be necessary. That it would be necessary is a sign of bad design.

Re:I'd rather have text than web

[RevAaron]

Until recently, I worked for a University Library. We had two apps that required the MS Java VM. One wouldn't work with anything but the MS VM, one did but was extremely unstable. Both apps are maintained, sold and supported and cost enough where you think they could live past the year 1998.

One of these apps is a library cataloging/integration package called Aleph by a company calld Ex Libris. Libraries- stay away from this, it's shit, and so is their support. The latter was determined through what my boss said to me, meaning I had to implement the stuff they had no clue about, but should have. This was something the state of MN has paid a whopping 4.3 million dollars for. It blows the mind- I'm in the wrong business.

Oh, just FYI: you can get the MS Java VM from Docutek's website, which is one of the apps we had that required the MS VM. Mind you, the MS VM is required for each remote user as well, and since most college kids who want to use our virtual reference service have the Sun VM installed already, it has resulted is nothing but crashes. Go Docutek!

So yeah, maybe 1997 called for their rant, but here in 2006 it isn't any better. At least it was easy to find the MS VM in 1997.

Re:I'd rather have text than web

[Anonymous Coward]

Fully agreed, and I'm writing webapps for a living.
Even as gmail as a nice example of a 'good' webapp it is still dog slow at times.
There are supposedly toolkits that make this stuff easier, but I havn't seen any that both clean up the server side mess AND client side mess that is webapps.

Don't get me started on doing something simple like designing a form. If this were a console UI I'd just need a few tabs and I'd be done with it. Instead I get to try and carefully align everything with elaborate css rules and then deal with such lovely quirks as firefox dynamically increasing the width of a drop down selection box to fit the biggest entry, but ie doesn't.

Ugh.

I don't even see why everyone gets their panties so wet over webapps anyways -- Everyones running XP+IE6 to the point where I have to target that and can safely ignore everything else. Why not just throw together a real client in something quick and easy like VB? If I was in control and a nice text-mode UI was out of the question, that would be my solution.

(anonymous for a reason)

Re:I'd rather have text than web

[644bd346996]

It is necessary because Java 5 changed things enough that it broke some compatibility with previous versions. They needed to do it to fix some bad designs in the original language. This is no worse than an updated C++ library changing the abi. Deprecated apis exist for almost all large code bases. On almost all systems, it is very easy to have and use both 1.5 and 1.4.2.

Re:I'd rather have text than web

[Anonymous Coward]

Gee, somebody call Microsoft, they seem to think the same thing is necessary for .NET; and call all the OSS people, my /usr/lib directory is filled with multiple versions of libraries.

Hope you have the solution for all these idiots!

Emacs!

[Watson Ladd]

Seriously, write it in Emacs Lisp. This will let you have a GUI and a command line interface with the same code.

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

omg

[ILuvRamen]

I can say from experiences that ANYTHING is better than the AS400 so it probably won't be worse no matter what you do. Chiseling stuff into stone tablets would be better. Ncurses is alright I guess, but I'd reccomend Visual Studio 2005 ;) lol jk

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:omg

[tehcyder]

I'd reccomend Visual Studio 2005 ;)

>>Flutter flutter flutter.

That's the sound of your karma flying off into the distance.

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?

Re:web based with lynx

[Anonymous Coward]

awesome! login as guest and try 'invaders'

Re:web based with lynx

[nuzak]

My hosting provider uses AjaxTerm, which is capable enough to run emacs.
http://antony.lesuisse.org/qweb/trac/wiki/AjaxTerm

Ncurses

[Psychotria]

Ncurses (New curses for those not familiar with it) is, as far as I know, the best solution to what you're asking. There's probably other libraries available, but I've never looked--Ncurses is tried, tested and does its job well.

Something you might look into

[iPaul]

Ruby has hooks for curses (Ruby is a fairly simple language). It also has a database API and an object relational layer ActiveRecord (part of Rails but doesn't require rails). You might take a look at that. You can extend Ruby using C if you need or you can write the C/C++ programs as callable from inside of the ruby script.

This is NOT something I've done before (except for using Ruby and Rails and the database api). But it might be something to take a peek at.

Re:Something you might look into

[Anonymous Coward]

Your post was a waste of electrons. Stop being a Ruby fanboy, and go with the tool that makes the most sense for this job. Namely, ncurses using C.

Re:Something you might look into

[knewter]

Bah, I could see ncurses/Ruby as being efficient. I've written a brief proof of concept similar to what he describes, and it was extremely speedy and robust for a quickly thrown together curses app. ActiveRecord, any ORM, I don't care - they mesh well with ncurses.

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

Re:Something you might look into

[Peter Cooper]

Hey, I've got 1992 on the phone here.

Using something like Ruby, Python, or even Java, for a non-performance console app is perfectly reasonable (and, IMHO, the best way) nowadays. C is an excellent language, but unless you're a C-god, you'll get better results in a shorter time with more dynamic languages in the 21st century.

Re:Something you might look into

[Marillion]

I've used Ruby curses. Ruby curses is a very thin layer on top of the classic C curses library (ncurses actually). There is no significant value add above direct C programming other than you get modern memory management that comes with a modern language like ruby.

The crown jewel of the Ruby world is ActiveRecord - although it's not included in the base distribution, it is easy to bolt onto any ruby installation. I can't think of any database layer in any language that is easier to use than ActiveRecord. ActiveRecord is also DBMS independent - Oracle, DB2, Postgress, Mysql and others.

The parent post called ruby simple. I agree that ruby is simple. But do not misconstrue that simple is weak.

Re:Something you might look into

[Anonymous Coward]

s/ruby/python/gi
s/ActiveRecord//gi

There. Fixed that for you.

Re:Something you might look into

[Storlek]

python has hooks for curses (python is a fairly simple language). It also has a database API and an object relational layer (part of Rails but doesn't require rails). You might take a look at that. You can extend python using C if you need or you can write the C/C++ programs as callable from inside of the python script.

This is NOT something I've done before (except for using python and Rails and the database api). But it might be something to take a peek at.

Should've trimmed out "rails" too.

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

[Anonymous Coward]

Coño!

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.

Re:pokey reference

[Inmatarian]

mod up, I hadn't thought of ANSI and he does make the point that it's a much better solution. To be helpful, here's the wiki link.

http://en.wikipedia.org/wiki/ANSI_escape_code

Re:pokey reference

[locokamil]

Consider yourself caned. Until your head falls off. I have some stories about conio that I'd like to tell you sometimes. Then you'll go and cane _yourself_ in the face.

Re:pokey reference

[JabberWokky]

Isn't conio utterly tied to the PC architecture? It was early on, I know. It just manipulated the video memory directly, making it utterly useless for this guy's needs (serial terminals).

--
Evan

Re:pokey reference

[pclminion]

That would be nice and all except that their particular terminal probably doesn't speak ANSI terminal codes. Just because it's ANSI doesn't mean it's used everywhere. In fact, I doubt ANSI is used in even a MAJORITY of the serial terminals still in use today.

The whole world is not a Linux terminal, or even anything close to it. ESPECIALLY not on AS/400.

Re:pokey reference

[644bd346996]

Nah - TurboVision is open source! It has been ported to linux.

Re:pokey reference

[tomhudson]

That would be nice and all except that their particular terminal probably doesn't speak ANSI terminal codes. Just because it's ANSI doesn't mean it's used everywhere. In fact, I doubt ANSI is used in even a MAJORITY of the serial terminals still in use today.

Wanna bet?

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.

menu or command?

[mechsoph]

If you want a menu driven interface, everybody's already said ncurses is the best game in town.

If you're looking for a command-driven interface, it might be cool to embed guile (GNU's scheme interpreter) in the program and use that for the front-end. Guile works with readline, and it would give you the added benefit of making the application scriptable (with a sane, elegant, and un-hacked-together-over-6-different-versions language), basically for free.

Re:menu or command?

[CoolGopher]

But beware that if you use anything that requires readline, your app will be under the GPL. This may or may not be a problem, but it's something you need to be aware of.

Re:menu or command?

[nuzak]

You can always link to libedit, which is compatible with readline, but is BSD licensed.

curses... !@#%*$

[LodCrappo]

I've run into similar requirements and ended up using ncurses and a couple higher level curses based libraries. not so bad really... and it does a very respectable job of working on various term types in case thats an issue for you. What more were you hoping to find? maybe there is a library that provides it if you were more specific in what you need. windowing, scroll areas, color, etc are all provided in curses anyways iirc.

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.

Re:Text based UI is underrated!

[Anonymous Coward]

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

Actually, that works great with web apps and web pages by default. In fact, the web is miles ahead of terminals in this respect. There are quite a few stupid web developers out there that go to great lengths to fuck it up, but that's what you get when you hire incompetent people, and I'm sure you'd get just as much of a mess if you hired incompetent people to code a terminal app too.

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

Again, I'd count latency as a downside to terminal apps, not web apps. Yes, web apps can be slower, but the browser provides user feedback when it's waiting on something, as opposed to terminal apps, which just hang until they get a response from the server. That's *way* more important than a few milliseconds shaved off the response time.

Re:Text based UI is underrated!

[Hatta]

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

Actually, that works great with web apps and web pages by default.

Really? I don't think I've ever seen a web page that scaled down its fonts when you resized the window. I just get scroll bars.

Re:Text based UI is underrated!

[EvanED]

But at the same time, every browser has ctrl-+ and ctrl-- to change text size. Opera goes further and scales everything somewhat uniformly, so the layout stays in the same proportions. (This has both advantages and disadvantages.)

It's not quite as nice as resize the window -> resize the text size, but it's not exactly a major disadvantage either unless you're constantly changing your layout. (Not to mention many terminals *don't* scale text size when you resize the windows, but do essentially the same thing the browser does.)

Re:Text based UI is underrated!

[Goalie_Ca]

You should thank the customer! Web apps are a nightmare.

Re:Text based UI is underrated!

[Anonymous Coward]

I agree that text based UI's are underrated.

In 2000, I worked for a very small (5 people) mail order photography store. We had a nice text based system. The owner decided it was time to get with the times and he purchased the newest version of the software which was a graphic UI. Almost every keyboard shortcut was eliminated and the tab order was atrocious. The other guys loved the new UI, as they got to use their mouse. Me? I prefer not to touch the mouse when doing data input in a call center, even as small as that one.

From 10/01 until 11/04 I worked in a mortgage call center. We received phone calls from banks and other lenders and purchased the loans they had made in order for them to free up money to loan to newer customers. Yes, we were part of the reason many people had to change where they sent their mortgage payment to. Anyway, we used three systems for our data entry. One system was on AS400 via a terminal window in Windows95. The other two were NLPS and LPS (I do not remember much about them except that I hated them. NLPS and LPS were both text based also, but LPS had a two step process. First the basics were done in a text UI, and then pulled into a graphics UI. That graphics UI had a bad tab order and only had three usable keyboard shortcuts, so I was forced to use the mouse. In my entire time there the AS400 system only went down once, and it was down for about an hour. However, the other two were down constantly. I don't care to know how they were networked or what the server was. I just know that many people hated the AS400 data entry system and loved the graphical UI entry system. I received a good number of pay raises due to my speed of handling customers. This was due to the text based UI of the AS400 system we used. The tab layout was clean; I could read the text no matter what I scaled the window to; Everything worked correctly; Keyboard shortcuts were efficient and well done. I loved that system. When I left they were trying to get everything switched over to a web based system. I tested that for them, I hated it. If it was not for the stroke at age 27 while working for them I would have quit when I hit 28, lol. I will never work attached to a phone again.

But to state again. A text based UI for data entry is much more intuitive and allows for quicker processing. Of course that is if the tab order and layout is done correctly. The mouse should only be used when designing graphics and such or when playing games. Data entry or word processing, it should not have to be touched at all.

Re:Text based UI is underrated!

[Qbertino]

Really? I don't think I've ever seen a web page that scaled down its fonts when you resized the window. I just get scroll bars.

I consider myself a web professional. And, curiously enough, what you're saying there is one of the prime reasons to use ... Flash. Flash is the only thing I know that is multi-plattform, has +90% reach, stays true to anything a designer would want *and* is completely independant of screen size or resolution when done right.
Sadly enough, even the elite of flash designers, usually being grafics people and unable to think beyond the concept of pixels and fixed pixel sizes. Most if not all screw up totally and push out fixed resoltion squint versions of their flash apps. When leading larger Flash projects, beating the concept of resoltion independence into their stupid sculls is a harder part of the job I usually have to get started with right away. The really sad thing is that it takes only 10 seconds of thinking and planning and 5 second of export settings to make your flashapp completely resolution independent. But even most of the most famous flashers are to f*cking stupid and incapable of doing it.
Proof positive: Check out (flash required)this alpha of a flash siteframe for dynamic CMS content and scale the browserwindow to see what I mean. (no bickering about design please, it's in alpha stage)

Bottom line: A web designer/programmer that uses flash and builds an app that isn't fit to scale down on a pocket pc is not worth his money. The exact oposite is a prime reason for using it. It's these countless half-assed flashers that give flash the bad reputation it has amoung many geeks.

Re:Text based UI is underrated!

[Anonymous Coward]

Again, I'd count latency as a downside to terminal apps, not web apps. Yes, web apps can be slower, but the browser provides user feedback when it's waiting on something, as opposed to terminal apps, which just hang until they get a response from the server. That's *way* more important than a few milliseconds shaved off the response time. This is only true when your users are unfamiliar with the app. When you are dealing with people who know the app, I would think they prefer speed to an hourglass spinning.

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.

Re:SLANG

[Anonymous Coward]

> ...programming ncurses is not really intuitive

That's to say you have no experience with
ncurses and no experience with slang either.
Try both. Then when you run away fromn slang
in despair take the curve to ncurses.

Re:SLANG

[Scarblac]

I used to use slrn (news reader) and jed (editor), they're both written using slang and both are fine programs. All have the same author - John E. Davis. So I would certainly look at slang.

That said, ncurses is the standard, it is mature, it is well known. You'd need to have some pretty special requirements before ncurses wasn't the best option, I think.

Re:SLANG

[Sigma 7]

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

The way to deal with obscure and hard-to-use APIs is to write a wrapper API. Your internal system works with it's own rendering primitives and when it's ready to refresh, it tells nCurses to update the screen. This is the exact same method I used for an attempt to write a 7DRL in order to both prevent clamping to a single development platform and to help speed up the development pace.

Re:SLANG

[Anonymous Coward]

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

Too bad we're on /. instead.

Oh, I get it...

Re:SLANG

[Blakey Rat]

I love how he capitalizes "Shell" in "shell script" but not "Slackware", which is actually a proper noun.

It truly is a work of art.

Re:SLANG

[pclminion]

It's funny. When I was learning C for the first time, I had been reading a lot of e.e.cummings concurrently. I remember thinking how much C looked like the poetry of e.e.cummings. He sure liked to use weird indentation, parentheses, inexplicable square brackets, etc.

I remember wondering if I could type in an e.e.cummings poem and actually get it to compile.

Re:SLANG

[mahangu]

I've used both shell + dialog and python + dialog, and can vouch for the usability of the library. It's an excellent choice for any text-based UI programming. For python, I'd use this nifty little wrapper - http://pythondialog.sourceforge.net/.

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.

Re:Try Charva

[Anonymous Coward]

It's nice and ncurses based. From the site:

How scalable is Charva? Can Charva handle multiple users in one JVM?
Because Charva uses ncurses, each user requires his/her own instance of Charva, in its own JVM.

Having said that, I've found that I can easily run 40 instances of the Charva "Tutorial" program (included with the download zipfile), each simulating a busy user, on a single-CPU Pentium with a 1.5GHz CPU and 768 MByte of memory. With this number of simultaneous instances there is no swapping of memory to disk.

Bearing in mind that (in 2006) RAM costs have dropped to, say, 25 US cents per megabyte, Charva is well suited for "intranet"-type data-capture applications with up to several thousand simultaneous users, provided you scale horizontally across multiple servers, with several hundred users on each server.

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:Turbo Vision!

[shenanigans]

Ahh, that brings back memories from the old Turbo Pascal days...

Re:Turbo Vision!

[The_Dougster]

I've been messing around with the sourceforge turbovision and it works on my Gentoo amd64 system, although there are some breakages in some of the classes.

It would be nice to see that lib get some much needed attention and fixups. It runs well in a linux console, inside an xterm, probably over ssh, etc.

I've been trying to make a Bash box run in turbovision, but no luck so far. The TTerminal class is the most broken part of the lib it seems.

Re:Emacs Trumps

[PylonHead]

So... not so hot on reading comprehension?

What's wrong with text screen GUIs?

[Anonymous Coward]

"Console apps can run *QUICKLY* on any old system of just about any OS or architecture with any speed CPU with any amount of RAM with any amount of bandwidth."

DesqView, PCtools for DOS.

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:What's wrong with text screen GUIs?

[shadowmas]

Console applications have a different but much more important feature.

Simplicity. Most console UI's are simple. unlike web/GUIs the console UIs are simple and restrictive which means the users have little choice and there is consistant way of doing something. you don't have to worry about what will happen if the user tries to select a different window and stuff. This type of environment is very very usefull for data entry and similar environments.

Re:What's wrong with text screen GUIs?

[RKThoadan]

Believe me, it's still quite possible to have inconsistent ways of doing things in a console GUI. I've used one system where viewing the next page of results required different keys in almost every sub-section. Like anything else, you need to agree on some standards right from the start!

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

gvim

[everphilski]

i I use gvim at work for programming in C++ / FORTRAN. Syntax highlighting works great. No complaints. Keyboard shortcuts / regexp / scripting make life a breeze. :wq

Re:gvim

[DreadSpoon]

And what the hell does that have to do with the question?

The question is about which text-based UI library is used, not which editor/IDE is used.

Re:gvim

[Anonymous Coward]

It has everything to do with the question that was asked in the title. It had little to do with the answer the editor or submitter thought they were asking, but that's their problem.

use Elinks

[Anonymous Coward]

Elinks combined with some simple cgi or servlets on the back end works like a charm.

Serial huh?

[Marrow]

So how many different kinds of serial terminal do they have
in their installed base. I hope they are not buying new ones.
Do you have keyboards/termcaps to make things more or less similar?

Linux is the server huh? So how many of these terminals are you putting
in the field; what is your multiport board solution? How many sites?
Are you going to have terminal servers? Are you going to have printers?

If you have multiple sites, are you going to use multiplexing between them?
Or are they going to use tcpip to get to the main site? Is your linux box
acting as a terminal server for a central TCPIP hosted connection?

Is the application a "fullscreen application"? Is it a database application
where the old 4gl languages already do most of your work for you? You could
write a simple database app in a day or so.

Are your serial terminals going to have serial printers strung off the back
and multiplex the terminal/printer datastream on one serial line? Or to do
screenprints? They are going to want screenprints in ANY application.

BTW, going back to serial is someones idea of hell -- mine.

Re:Serial huh?

[Marrow]

We created a lot of serial apps on Informix/4GL. I
guess IBM bought informix. It still exists.

Gopher

[Nimey]

Lots of style points if you give them an old-fashioned Gopher intranet and Jughead search.

Re:Gopher

[flyingfsck]

Wow, Gopher, Archie, Jughead and Veronica... I wonder whether anybody else knows what you are talking about!

Re:Gopher

[JabberWokky]

Plenty of us still remember our bang path to uunet. My first comment on a pre-1.0 web browser was "nice, but it won't ever replace gopher... too many people use it and there's just too much information already formatted to gopher". Whups.

--
Evan

I see I'm not the only one...

[kantier]

that read the title and saw a "Vi vs. Emacs" flamewar in the horizon (or right after the click, whichever you prefer). I was even planning to tag this article "oldnewsflamewar" or something like that...

Sorry, I don't have an answer to your question, but what I can say is that the title was a little bit confusing.

~Kant

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

JavaServer Faces

[jazir1979]

This may well be overkill, but if for your backend code you do want to go down the Enterprise Java route, then JSF is *supposed to be* independent of the view technology. Well-written component libraries will provide pluggable renderers. Most libraries do just have HTML renderers for the components, but Oracle's ADF (now open-sourced as Apache Trinidad) provides JSF over telnet:

http://www.oracle.com/technology/tech/java/newslet ter/articles/introadffaces/index.html

Assuming it works, that is pretty cool, and it means your server-side can leverage the rich JEE technology suite.

Re:JavaServer Faces

[jazir1979]

I probably don't need to spell this out, but a prime advantage of this is that you could support text AND html based clients, or at least switch to a HTML web-app quite easily in the future if requirements change.

TurboVision

[swillden]

When I was writing text-based PC apps in the early 90s, Borland's TurboVision blew me away. It was very easy to work with and it made building nice, windowed user interfaces a snap. Not only that, but full source was provided and that source was clean, elegant, and such an excellent demonstration of proper object-oriented design that I built an OO design class around it.

Borland released TurboVision to the world after it was obsoleted by the takeover of GUIs, and some enterprising folks have ported it to gcc/ncurses and fixed up some of the few defects in the original library.

I haven't actually used this library, but its existence almost makes me want to go write some text-mode code just for the fun of it.

you say ncurses. . .

[chinakow]

. . . like it is a bad thing. HP used to used a terminal based ticketing system for their 4 hour response tech support, they just HAD to move to a new point and click system. Don't worry it will be waster they said, it wasn't. Even after months of getting used to the system it was still slow because one would have to click through multiple tabs to enter text. The old system you just typed and if you needed another screen your hands where already on the keyboard so you typed a simple keyboard cord and you where there, no moving one hand to the mouse, finding the cursor, movings it over to the little tab, clicking and moving your hand back to the keyboard. It was nice, but then someone thought that GUI was the answer to every interface problem and that was the end of working fast.

Re:you say ncurses. . .

[moco]

Nothing beats text mode for fast data entry but a well designed graphical or web UI does not have to slow you down. For starters you don't need the mouse at all if the correct tab order is used in the entry elements AND if the order of the elements is modeled after the most common usage of the application.

Now, for the original question, if C/C++ is not a requirement then the solution proposed by jazir1971 is a very good one unless the server hardware is limited. I did not understand the nature of the application, but if it is a db-driven one i'd recommend this route because db-intensive apps in C/C++ are generally not a good idea.

If C/C++ is a requirement, there was (is?) an abstraction built on top of ncurses called libdialog that features textboxes, menus, option buttons, lists and other gui-like stuff. It may be of use. I remember the first (and last) time i used it (around 1995), it was a bit painful but did the job.

Re:you say ncurses. . .

[mollymoo]

That's not a problem with GUIs in general, that's a problem with one example of a (badly implemented) GUI. The problem you documented would be solved by simply providing a keyboard shortcut (perhaps even using the same chord as in the terminal version) to change between tabs. GUIs are prefectly capable of being fast, intuitive and keyboard-driven.

Re:you say ncurses. . .

[SheeEttin]

At my dad's florist shop, he used to run one Solaris server with 6-7 serial terminals running off it. Worked great, the F keys were used to navigate fields and when you typed, text was entered. Simple and efficient.

Now, though, it's a Red Hat server, with multiple Windows XP machines running TinyTERM to get to the Red Hat box. No idea why.

Re:you say ncurses. . .

[chinakow]

a fast GUI is possible but if you are only doing text entry then why do you need Graphics? The point it that a console based system can work on a dumb terminal and any system that came out last week. Just install PuTTY if it is windows or open a terminal on any other OS and your client side install is done. With a decent text interface, the system becomes fast to install and fast to use.

Re:you say ncurses. . .

[tenco]

That's exactly the reason why i hate Web 2.0. No shortcuts.

Urwid?

[Argon]

When I saw this post on slashdot, the top Freshmeat item is coincidentally a python based Text UI library called .

Re:Urwid?

[nuzak]

> library called .

Quite a mouthful. That'd be urwid (which is perhaps as meaningful as that dot).

What's wrong with asinine?

[Anonymous Coward]

"Slapping a web server on an embedded system just so you can interface to them is beyond asinine."

Shhh! Don't tell Brandybuck about this.

Re:What's wrong with asinine?

[iminplaya]

I believe you just made his point :-)

Re:What's wrong with asinine?

[Brandybuck]

Putting an httpd configuration page on a network device isn't that terrible. But making it the ONLY way to configure it, is still asinine. Even worse are the IE-only routers.

But oh well. Finding a laptop that even has a serial port these days is nigh impossible. The make-everything-a-webapp assholes have won, damn them!

Python + ncurses is all right

[Dh2000]

But, unless you use an extra widget library you will be spending an excessive amount of time writing your own (or quickly growing wise and stealing one). Ncurses has just the bare minimum of widgets: windows, sub-windows, text, and special characters. Since I used raw ncurses, I ended up spending quite some time making my own curses apps act somewhat similar to a typical GUI application.

The size of the terminal forced me into text processing and cropping... roughly a third of my app is just processing text to fit into the size constraints of its particular 'window'. The rest is processing data, and managing and decorating the various sub-windows.

Things get more complicated when I added mouse support and "tabs". But, the most annoying bit is not having a standard terminal that everyone uses. Often function and meta keys don't work, or - for putty and TTY users - the mouse doesn't.

Anyhow, in the real world, if you have the option of using a GUI instead of a curses-based app, I suggest you take it. Using curses takes a lot of the speed out of writing a normal python application, and is often tedious to the point you realize why curses was named.

Gaim Ncurses Toolkit (GNT)

[sabit666]

Check out gaim-text. It uses a new ncurses based toolkit that emulates GTK+. If you are familiar with GTK+, you will like it.

Re:Gaim Ncurses Toolkit (GNT)

[JHWH]

It sems to be great! But there is no documentation and even the author seems to be unreachable.
Any hint apart of reverse engineering the gaim-text?

Re:Gaim Ncurses Toolkit (GNT)

[Anonymous Coward]

1. You don't need to 'reverse-engineer' gaim-text, since the source code for both libgnt and gaim-text are available (http://svn.sourceforge.net/svnroot/gaim/trunk/con sole/)

2. How did you try to reach the author? Try sadrul@users.sourceforge.net

Re:Emacs Trumps

[Anonymous Coward]

So... not so hot on reading comprehension?

Aha! You must be a vi bigot!

(Ok, so soloport is a moron. At least he has good taste in text editors.)

tip1 = Try to do both; tip2=Text web!

[Nicopa]

Try, if you can, to either use a technology that abstracts you from the UI or simply isolate your core logic from the interface. That way you could provide both a web (or graphical) ui and a text ui. If they see the GUI is more usable they could end up with it.

Another tip: You could suggest creating a web application and make a Lynx (or Links) friendly webapp. Those text web browsers will run over telnet and they will be very friendly for them, as they share the "form orientation" of AS/400 form oriented 3270 terminals.

Qt?

[Anonymous Coward]

That way, you don't have to write ugly callback routines everywhere. Signals and slots are nifty features that allow you to focus on the higher level logic rather than the nitty-gritty stuff. If/when it comes time for porting the application to other languages, you'll thank yourself.

Disclaimer: I do not work for Trolltech or any of its affiliates.

Re:Qt?

[Anonymous Coward]

If you consider something as simple as a callback to be "nitty-gritty" then I wonder what you do when presented with a TRULY challenging task. Like, say, adding two numbers together.

How about eLinks instead of Links?

[antdude]

Home Page for eLinks.

Perl or Python + ncurses

[jschmerge]

A couple of years ago I had to create a configuration system for FreeBSD systems in a data center... What I ended up using was a really crappy Perl module called PerlVision to do it (I was basing the code on a config system someone else wrote for some other systems). Anyway, it was pretty painless to do. You might consider writing the UI using a scripting language like perl or python that expose the ncurses bindings and use that to start any back-end processing that needs to happen. Also, as a design point, you might consider saving the configuration in a flat file that the backend reads. That way you can separate the UI development and testing completely from the actual product... If the need ever arises to create a fancier UI, you'll be able to then do it fairly painlessly.

Re:Perl or Python + ncurses

[Anonymous Coward]

What part of "the language will be C or C++" did you not understand?

ncurses it is

[bar-agent]

So, yeah. Looks like no-one has any better recommendations...and little to say that's constructive at all, for that matter.

Term::ReadKey

[Anonymous Coward]

When I do console-based stuff for whatever, I usually use Perl, and I usually have some common Term::ReadKey stuff. E.g., I do GetControlChars, go into ReadMode 'cbreak', append entered chars to a string (or chop them off if the entered char eq $ctrl{'ERASE'}), etc. etc.

I know you said C or C++, but two cents goes here.

Anything Specific?

[Anonymous Coward]

Is there anything specific about the AS400 that you think is inferior to other platforms? While it does have some weaknesses, it also has a large number of very important strengths.

Which Text-Based UI Do You Code With?

[cakefool]

MSBasic of course.

What?

What?

Re:Python and ncurses would make a good combinatio

[Anonymous Coward]

The man ask for a UI advice and out come the Python zealots....

go web

[countach]

Umm, simple web pages are low bandwidth yet provide a much richer interface than curses. And you'll actually be living in the 21st century by using it with programmers who like to program it and have experience with it. And you can upgrade it slowly over time if and when bandwidth inproves. What is the problem? But an ncurses solution one say will probably have to be abandoned wholesale one day.

Re:go web

[Jesterboy]

Tell me when you write a "simple" (non-AJAX) webpage that implements the same functionality as vi, and then we'll talk. ^_^

We're well into the 21st century, and I see as many text based facilities as at the end of the 20th century. Like it or not, the console is not going away.

Before you torture yourself with ncurses

[OeLeWaPpErKe]

Check this out : http://tvision.sourceforge.net/

Yep, the old turbo vision. Very useful, object oriented, shortcut keys built-in. Mouse handling, very fast, very well debugged. Great stuff

Serial ought to be compulsory for web designers..

[cheros]

I personally think that it ought to be compulsory for web designers to work through a 9600 baud straw, no make that marketing people, as they tell them what to do. It teaches them to be efficient and focus on what a web page needs to do: deliver information. Only after that job has been done can you think about making it look pretty. I'm actually in favour of what Attrition.org has done although that is a bit too stark - it is very effective.

I personally don't even bother to wait for Flash and sound crap to load up - that's a sales lead lost for a company.

Now, I've grown up with serial from my first 75/1200 baud modem to using serial controlled system and the main pain was getting the physical wiring right (XOFF is your friend :-) - after that it was mostly seriously robust. I haven't tried a wet piece of string but that would have probably worked as well, and once you know what you're doing a paired modem setup isn't that hard either.

So I wouldn't call it hell - it worked. Hell was hiding in Wyse VT100 terminals that were user configurable because if a user can, a user will - that hasn't changed over the years :-).

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.

Links is a great idea

[NekoXP]

Simply code up a web-based system which looks good in Links - since the Twibright build can do rudimentary Javascript and table and frame formatting, works over a serial terminal, you can solve it for ALL your customers at once with one unique solution. You can still code the back end in C/C++.

One thing I *am* curious about, does Links support AJAX? I don't mean whizzy huge operating-system applications, just XMLHttpRequest and the ilk? Just the simple stuff, no graphics or so, just for form validation and background processing or so (it's very useful for status monitoring..)

readline

[YGingras]

Don't try to make a graphical app on a text based terminal. Just do a good text based intercafe with readline. Be it gdb, the python shell, mysql client, or just bash, a good readline enabled app is fun and efficient to use. You can TAB-complete (not enabled by default in python but you can have it), search history with CTRL-r and cut/yank a bunch of tokens at a time when you edit your command. OK the line editing shortcuts are usually over optimized for emacs users (did you know that M-u upcase a word in bash?) but you are free to rebind them.

Pardon me for noticing, but...

[haakondahl]

...A guy with a nick of JHWH is asking for professional advice? I hope your name is John Herbert Walker Hoover. Just Sayin'...

GNUE?

[martinde]

Never tried it myself, but I believe they separate the data modeling from the presentation layer so you can target text clients, GUI clients, or web clients. Here is a screen shot showing forms presented on the various renderers.

Java textbased UI

[Anonymous Coward]

There is a nice text UI for Java, that uses a subset of the Swing API:

http://www.pitman.co.za/projects/charva/

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:Web application vs Java Webstart

[Blakey Rat]

I hate to break this to you, but there are still tons of huge medical software corporations using 1997's applets. Next time I come across the problem, I'll be sure to forward your message on to IBM and Siemens, k?

Here in the real world, I came across that real problem in the recent year of 2004. Maybe even early 2005.

Re:Web application vs Java Webstart

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

Not really news. I have implemented a JApplet for a real-world-client (it's funny that that was a pharmaceutical company, BTW) in 2004. Just take precaution to make it reusable in another context (inherit form JPanel instead of JApplet) and be prepared to handle the '97s type of problems that come with it...

And the world turns despite the big molochs, currently working with some IBM guys. Sigh. Certified clue free variety. But nice people in all other respects.

Menus, menus, menus

[VernonNemitz]

A GUI is really just an alternate way to present a menu of choices to the user. So a text interface that is versatile enough to support several levels of menus should be completely workable.

Re:Menus, menus, menus

[scdeimos]

Absolutely. They've even ported TurboVision to X and ncurses which would provide a lovely interface. (No, seriously, I've always liked TurboVision.) What I was trying to point out is that there is a requirement to work with the existing serial terminals - DOS and DESQview just aren't going to work for them.

Why not DECforms?

[nbvb]

On OpenVMS?

No, I'm not being facetious. It still works great. Especially over those serial connections.

http://h71000.www7.hp.com/commercial/decforms/

let's see...

[whitroth]

Now, I use vi, but you could run that would-be o/s emacs, and just fill it up with macros....

                    mark

Pico!

[LanMan04]

I use Pico, mainly because it's dead-simple and it's what my undergrad institution got me hooked on when I was just getting started with Linux/UNIX-land.

During grad school I wrote a recursive-descent Pascal compiler in Java using just plain old Pico; I guess my needs aren't that complex.

VI is the Only One

[Ferretman]

I've used VI ever since I discovered it in 1990....can't imagine going back.

    It's clunky, non-intuitive, and frustrating...and enormously powerful, super fast, and doesn't take my hands off the keyboard. I don't know a fraction of the commands available but my *fingers* do, and I'm constantly astonishing those I work with by how fast I can edit something with VI while they're still bringing up nedit.

    VI all the way.

Steve
From the High, Snowy Mountains of Colorado

Re:VI is the Only One

[Richard Steiner]

There are so many text editing paradigms that it's hard for me to imaging only using one. That way lies stagnation, methinks. :-)

When comparing vanilla vi to NEdit, I find things like syntax highlighting, concurrent file editing, and ctags support to be large advantages. YMMV...

Obligatory Terry Pratchett quote:

[pruneau]

"It's the century of the fruitbat, after all !!!"

Oh, and be very carefull: having to run through a serial line and beeing forced to use lynx _and_ a web server is quite _not_ the same, dude.

Use ncurses

[ajs318]

Use ncurses, just write your own wrapper functions to make it look a bit less scary. If you ever want to upgrade to a web-based interface later, you can just drop different code into your wrapper functions. I've written a few Perl scripts that detect environment variables set by the Apache server (or not) and based on that, either parse forms and generate HTML output with its own headers or read parameters from the command line and generate plain text output. Although you'll be using C, the principle is more or less the same.

It's tempting to say hard-code in control sequences for the terminals you're using ..... that'll work great iff the terminals are all the same kind and you keep them forever. If you've a strange mix of VT-100, VT-220 and non-ANSI terminals (entirely possible with a mainframe system that's been expanded over time; when I was at Uni we had a strange mixture of real VT-220s, VT-220-alikes, VT-102-alikes, one or two real VT100s and many non-ANSI terminals connected to an assortment of 11/750s and 780s, a cluster of 8650s and some sort of unix box by Sequent), it's not even an option.

Lynx, really.

[Anonymous Coward]

The comment posted about using the lynx text mode browser and making it web based was actually a very good idea.

Why? Because in 5 years they'll come back saying "We really need this to work on a web page."

We've done this before where I work when people are used to seeing those CICS screens and its proven effective.

Javascript or Flash of course!

[foniksonik]

You've come a long way baby.... just make a nice console like app, maybe something influenced by Lawnmower man, Hackers, any Keanu Reeeves starring future movie or Swordfish and you'll blow them away! Use all flash and actionscript!!!!

If you want to get fancy, write the whole thing as an openGl app with hooks into the system and just use bash or tch as your CLI ;-p but make the text have volume so it's 3D and put it on a touch screen display with a virtual keyboard.... if you want to be cool that is.

Re:Serial ought to be compulsory for web designers

[Marrow]

The devil is in the details:

1. Get the wiring right. After you do that, the wires can only do one thing at a time
unlike network cable which automagically multiplexes.

2. If you have a lot of terminals, then you need to get them ALL wired independently to
the machine using multiport boards. Or use network-based terminal servers. Both points
of failure that have their own problems.

3. If you have sites at remote locations connected via a modem, then you have a whole 'nuther
can of worms. How does your application respond to the modem dropping connection. Does the
workflow handle going back in and picking up where the customer's order left off.

4. Are you going to write your app to "have an image of the screen in memory" so that the
screen can be refreshed when errant characters flip up. Or when that modem connection is
lost?

5. If you have a "graphics" terminal, can those graphics be printed to the printer. Are
you going to have multiple apps with page flipping via screen or some other tool. And
what happens when some of those esc sequences are lost and the screen goes nuts. They
need to be able to work on more than one thing at a time.

6. If you are using terminal servers, then they have their own menus and own problems.
Some people are going to have PCs. Are you going to use a rs232 terminal emulator with
them or are you going to give them a network client. What about the terminal differences
between your hard terminals and those software packages.

7. Multiport/tty drivers have been buggy in my experience.

Serial is NOT stable. It is NOT versatile. And by the time he is done with the project,
the guys in charge will have realized that the bandwidth they were worried about was
a small issue.

They probably have an installed base of dumb terminals, or they have a brain tumor. Or both.

Plan 9 has some answers, even for Linux boxes

[DrSkwid]

You could use Sam - written with remote editing across slow serial lines in mind.

Or import the remote file system in using srvssh in plan9 or p9 in p9port and use Acme

Plan9port is a port of the Plan 9 userland to Linux / BSD / OSX

Re:Plan 9 has some answers, even for Linux boxes

[DrSkwid]

You could also use a 9p enabled Linux kernel like Ubuntu and import the remote file system into your local file tree using v9fs

Vermont Views

[mountainman]

Vermont Creative Software still sells Vermont Views, a C library of text windowing and data-entry functions. The serial terminal version runs under Linux and handles different terminal escape codes with a termcap-like file.

Higher-level libraries

[cananian]

"apt-cache search curses" on debian yields a number of higher-level libraries (built on curses) that can simplify your work. For example: libaca "The Advanced nCurses API", libcdk ("curses-based widget library" in both C and perl), libcurses-ui-perl, libcurses-widgets-perl, libperlmenu-perl, libtexttools ("ada and c++ library for writing console applications"), python-urwid ("curses-based UI/widget library for Python"), twin ("Text mode WINdow environment"). So, I think the previous posters who mentioned ncurses are on the right track, but you probably want to use one of these other libraries as well, so you don't end up reimplementing menus, thermometer widgets, etc.

Why Pick, When You Can Have Both?!

[LionKimbro]

Try out the demo for Urwid.

You can use both desktop text user interface, and web based text user interface.

AND, It's open source!

Now how much would you pay?!

Re:VIM

[Fyre2012]

Personally, and I'm sure others would agree, I find VI(M) to be horribly user-unfriendly for someone who wants to do web coding.

I have a fancy for Nano after i discovered it during my first bout with Gentoo.
I can't say I've needed to look back since. It's quick, intuitive, and shell-friendly =)

CDK comment

[gamartin]

After a large project making extensive use of CDK my conclusion is that CDK is half-baked as a windowing toolkit -- it lacks a cohesive philosophy for redrawing the screen that you expect in a windowing toolkit. It needs somebody with real GUI experience to re-engineer it. TurboVision looks interesting and refined, though I've never used it.

After observing the range of problem I hacked up CDK and produced a version that at least behaves sanely for layering components on top of each other and having them refresh properly to the screen.

However, my patch submissions were ignored by the CDK maintainer -- if anybody wants to do something with them just ask.

Re:CDK comment

[Anonymous Coward]

I am interested.

Which CDK library were you using: Vexus' at http://www.vexus.ca/products/CDK/ or Thomas E. Dickey's at http://dickey.his.com/cdk/cdk.html?

Can you do it with dialog?

[pclminion]

"dialog" is a curses-based program that throws up dialog screens based on options you give on the command line or a config file. The fact that you are considering a web-based solution with lynx makes me think that you don't need super-complex functionality -- dialog might be enough to do what you need. Essentially, the highest level of your user interface will be a shell script. The back end can be anything you want -- I would communicate with it via pipes of some kind.

Why no lynx?

[GWBasic]

Why no lynx? Is this a case where your client needs to be gracefully guided to the 21st century, or is this a case where your client has a real need for a text-based solution?

Dr. Dobbs used to have one in 90's

[Anonymous Coward]

Please check the website ddj.com, they used to have a nice one written in C.

Re:Python and ncurses would make a good combinatio

[caseih]

Spoken by a true non-zealot who's obviously never tried python.

By the way I am not a python programmer nor do I use it regularly, but for some things it is the right tool for the job.

LOL :-)

[cheros]

Your post reads like I was suggesting that he ought to continue using serial circuits. Nope.. The key two problems are (1) scalability and (2) legacy technology, it's brutally inflexible and it's hard to get parts for at a sensible price so there are maintenance issues. I'd emulate it straight at the box and carry it over the LAN (and start planning for replacement).

It's been a while since I touched this stuff, though, 14 years or so. The last time I did it I turned a monthly 2 man weeks worth of report rekeying into 15 mins worth of processing of the same report using Kermit (file transfer), Turbo Pascal (cleaning up the result as I couldn't get the report changed) and Paradox for data handling and subsequent stock despatch notes. I wasn't even a coder, we just put this together because it was so glaringly obvious a fix that it would have been embarrassing not to do it (Primal IT: fixing an itch 8-).

And no, I don't really miss those days - that company wanted the stars but wasn't prepared to even pay peanuts (classic British management, I guess they developed that style in the colonies) so I walked pretty soon afterwards.