×

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

Thank you!

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

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

Which Text-Based UI Do You Code With?

Cliff posted more than 7 years ago | from the ain't-nothin'-wrong-wit-curses dept.

GUI 211

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

211 comments

What's wrong with ncurses? (3, Insightful)

Secret Rabbit (914973) | more than 7 years ago | (#17468784)

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

Re:What's wrong with ncurses? (1)

poopie (35416) | more than 7 years ago | (#17468936)

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.

Emacs Trumps (-1, Flamebait)

soloport (312487) | more than 7 years ago | (#17469060)

Emacs is the ultimate productivity suite. Edit, using macros, compile, jump-to-errors, debug (e.g. gdb) all within the comfort of a lisp-extensible platform. Used to be, when all one had was a 1200bps modem, it was amazing to watch how Emacs re-drew a page of text -- very efficient.

Re:Emacs Trumps (1)

PylonHead (61401) | more than 7 years ago | (#17469158)

So... not so hot on reading comprehension?

Re:Emacs Trumps (2, Insightful)

tomhudson (43916) | more than 7 years ago | (#17469236)

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

Re:Emacs Trumps (0)

Anonymous Coward | more than 7 years ago | (#17469718)

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

What's wrong with text screen GUIs? (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17469206)

"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? (2, Informative)

scdeimos (632778) | more than 7 years ago | (#17470318)

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? (1)

shadowmas (697397) | more than 7 years ago | (#17470780)

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 ncurses? (2)

Brandybuck (704397) | more than 7 years ago | (#17469368)

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.

What's wrong with asinine? (1, Funny)

Anonymous Coward | more than 7 years ago | (#17469554)

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

Re:What's wrong with ncurses? (1)

jonabbey (2498) | more than 7 years ago | (#17469064)

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? (1)

tomhudson (43916) | more than 7 years ago | (#17469294)

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? (4, Interesting)

SnarfQuest (469614) | more than 7 years ago | (#17469632)

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? (1)

kfg (145172) | more than 7 years ago | (#17469620)

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? (1)

Secret Rabbit (914973) | more than 7 years ago | (#17469910)

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? (1)

kfg (145172) | more than 7 years ago | (#17470866)

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? (1)

iangoldby (552781) | more than 7 years ago | (#17470896)

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? (1)

EvanED (569694) | more than 7 years ago | (#17470052)

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.

what's the problem? (3, Insightful)

Anonymous Coward | more than 7 years ago | (#17468812)

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? (2, Insightful)

belmolis (702863) | more than 7 years ago | (#17470004)

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

Ncurses it is. (1)

liftphreaker (972707) | more than 7 years ago | (#17468818)

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 (4, Insightful)

Blakey Rat (99501) | more than 7 years ago | (#17468826)

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 (2, Insightful)

jonabbey (2498) | more than 7 years ago | (#17469086)

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 (1)

clem.dickey (102292) | more than 7 years ago | (#17469286)

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 (2, Informative)

jonabbey (2498) | more than 7 years ago | (#17469434)

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 (1)

Brandybuck (704397) | more than 7 years ago | (#17469288)

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 (0)

Anonymous Coward | more than 7 years ago | (#17469290)

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 (1)

Scoldog (875927) | more than 7 years ago | (#17469332)

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 (2)

stefanlasiewski (63134) | more than 7 years ago | (#17469862)

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.

Emacs! (1)

Watson Ladd (955755) | more than 7 years ago | (#17468886)

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

omg (0, Troll)

ILuvRamen (1026668) | more than 7 years ago | (#17468910)

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 (3, Insightful)

ralphdaugherty (225648) | more than 7 years ago | (#17469494)

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

Anything Specific? (0)

Anonymous Coward | more than 7 years ago | (#17470446)

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.

Ncurses (1)

Psychotria (953670) | more than 7 years ago | (#17468924)

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.

VIM (-1, Offtopic)

snowgirl (978879) | more than 7 years ago | (#17468926)

I'm totally for VIM, or do you mean for people to interface with, rather than code in?

Then I'd probably look at ncurses.

Something you might look into (1, Redundant)

iPaul (559200) | more than 7 years ago | (#17468956)

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 (0)

Anonymous Coward | more than 7 years ago | (#17469820)

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 (1)

knewter (62953) | more than 7 years ago | (#17470044)

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 (1)

Peter Cooper (660482) | more than 7 years ago | (#17470698)

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 (2, Insightful)

kbob88 (951258) | more than 7 years ago | (#17470592)

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

pokey reference (3, Funny)

Inmatarian (814090) | more than 7 years ago | (#17468984)

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 (0)

Anonymous Coward | more than 7 years ago | (#17469076)

Coño!

Re:pokey reference (2, Interesting)

tomhudson (43916) | more than 7 years ago | (#17469354)

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 [ufcg.edu.br] 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 (1)

locokamil (850008) | more than 7 years ago | (#17470496)

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.

Python and ncurses would make a good combination (3, Informative)

caseih (160668) | more than 7 years ago | (#17469032)

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.

Re:Python and ncurses would make a good combinatio (0)

Anonymous Coward | more than 7 years ago | (#17470580)

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

menu or command? (1)

mechsoph (716782) | more than 7 years ago | (#17469048)

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? (1)

CoolGopher (142933) | more than 7 years ago | (#17470670)

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.

curses... !@#%*$ (1)

LodCrappo (705968) | more than 7 years ago | (#17469054)

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! (5, Insightful)

mikeburke (683778) | more than 7 years ago | (#17469070)

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! (2, Interesting)

iPaul (559200) | more than 7 years ago | (#17469166)

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! (2, Insightful)

mmogilvi (685746) | more than 7 years ago | (#17469444)

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! (0)

Anonymous Coward | more than 7 years ago | (#17469742)

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! (1)

Hatta (162192) | more than 7 years ago | (#17469922)



        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! (1)

EvanED (569694) | more than 7 years ago | (#17470024)

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! (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17470452)

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.

SLANG (4, Interesting)

goarilla (908067) | more than 7 years ago | (#17469092)

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/ [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 (0)

Anonymous Coward | more than 7 years ago | (#17470576)

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

Scarblac (122480) | more than 7 years ago | (#17470788)

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

Try Charva (2, Informative)

jpavel (129734) | more than 7 years ago | (#17469100)

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

Turbo Vision! (2, Interesting)

pestilence669 (823950) | more than 7 years ago | (#17469146)

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

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

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?

gvim (0, Offtopic)

everphilski (877346) | more than 7 years ago | (#17469242)

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 (1)

DreadSpoon (653424) | more than 7 years ago | (#17470162)

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.

use Elinks (0)

Anonymous Coward | more than 7 years ago | (#17469262)

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

Serial huh? (1)

Marrow (195242) | more than 7 years ago | (#17469278)

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? (1)

Marrow (195242) | more than 7 years ago | (#17469344)

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

Serial ought to be compulsory for web designers.. (1)

cheros (223479) | more than 7 years ago | (#17470994)

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

Gopher (1)

Nimey (114278) | more than 7 years ago | (#17469282)

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

Re:Gopher (1)

flyingfsck (986395) | more than 7 years ago | (#17470516)

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

I see I'm not the only one... (1)

kantier (993472) | more than 7 years ago | (#17469326)

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 (2, Informative)

John Hasler (414242) | more than 7 years ago | (#17469404)

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 (1)

jazir1979 (637570) | more than 7 years ago | (#17469414)

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

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

Re:JavaServer Faces (1)

jazir1979 (637570) | more than 7 years ago | (#17469652)

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 (1)

swillden (191260) | more than 7 years ago | (#17469446)

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 [codegear.com] after it was obsoleted by the takeover of GUIs, and some enterprising folks have ported it to gcc/ncurses [sourceforge.net] 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. . . (1)

chinakow (83588) | more than 7 years ago | (#17469460)

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

moco (222985) | more than 7 years ago | (#17469782)

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 [slashdot.org] 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. . . (1)

mollymoo (202721) | more than 7 years ago | (#17470246)

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.

Urwid? (1)

Argon (6783) | more than 7 years ago | (#17469536)

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

Python + ncurses is all right (1)

Dh2000 (71834) | more than 7 years ago | (#17469598)

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) (1)

sabit666 (457634) | more than 7 years ago | (#17469678)

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

tip1 = Try to do both; tip2=Text web! (1)

Nicopa (87617) | more than 7 years ago | (#17469766)

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? (0)

Anonymous Coward | more than 7 years ago | (#17469858)

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.

Perl or Python + ncurses (1)

jschmerge (228731) | more than 7 years ago | (#17470296)

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 (0)

Anonymous Coward | more than 7 years ago | (#17470882)

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

ncurses it is (1)

bar-agent (698856) | more than 7 years ago | (#17470300)

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

Term::ReadKey (0)

Anonymous Coward | more than 7 years ago | (#17470314)

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.

go web (1)

countach (534280) | more than 7 years ago | (#17470740)

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 (1)

Jesterboy (106813) | more than 7 years ago | (#17470938)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

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

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

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

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...