Follow Slashdot stories on Twitter


Forgot your password?
GUI Software

Which Text-Based UI Do You Code With? 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?"
This discussion has been archived. No new comments can be posted.

Which Text-Based UI Do You Code With?

Comments Filter:
  • by Secret Rabbit ( 914973 ) on Thursday January 04, 2007 @10:45PM (#17468784) Journal
    IMO, unless you can give a good reason why you shouldn't use ncurses, use it.
    • by poopie ( 35416 )
      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.
      • 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.
    • by jonabbey ( 2498 ) *

      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

      • 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
        • by SnarfQuest ( 469614 ) on Friday January 05, 2007 @12:40AM (#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: (Score:3, Interesting)

            by tomhudson ( 43916 )

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

            • Re: (Score:3, Informative)

              by ByTor-2112 ( 313205 )
              "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 quest
            • 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 beginnin

      • by cyclop ( 780354 )

        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.

    • 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.
      • by SenFo ( 761716 ) on Friday January 05, 2007 @08:56AM (#17472092) Homepage
        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.
        • 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.

 [] if anyones curious for an example. This was back when 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.
  • by Anonymous Coward on Thursday January 04, 2007 @10:47PM (#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: (Score:3, Insightful)

      by belmolis ( 702863 )

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

      • Re: (Score:3, Insightful)

        by Arker ( 91948 )
        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: (Score:2, Insightful)

          by 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'
  • by Blakey Rat ( 99501 ) on Thursday January 04, 2007 @10:48PM (#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: (Score:3, Insightful)

      by jonabbey ( 2498 ) *

      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

      • 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: (Score:3, Informative)

          by jonabbey ( 2498 ) *

          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

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

            • 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.
          • 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.
      • 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.
      • 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 M
        • 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 bos
      • by Builder ( 103701 )
        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.
  • Seriously, write it in Emacs Lisp. This will let you have a GUI and a command line interface with the same code.
  • by lpcustom ( 579886 ) on Thursday January 04, 2007 @10:59PM (#17468920)
    Just for shits and giggles make it web based and force them to use lynx to interface with it.
  • 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: (Score:2, Insightful)

      by kbob88 ( 951258 )
      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 execu
    • 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

  • by Inmatarian ( 814090 ) on Thursday January 04, 2007 @11:04PM (#17468984)
    This should get me modded down and/or knocked unconscious from repeated canings to the face or something.


    Isn't there a linux port of that?
    • Re: (Score:3, Interesting)

      by tomhudson ( 43916 )

      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). t ml [] ansi escape sequences.

      You can clear the screen, home the cursor, more the cursor to specific coordinates, erase to the

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


  • by caseih ( 160668 ) on Thursday January 04, 2007 @11:11PM (#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.
  • 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.

    • 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.
  • 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.
  • by mikeburke ( 683778 ) on Thursday January 04, 2007 @11:16PM (#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: (Score:3, Interesting)

      by iPaul ( 559200 )
      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: (Score:2, Insightful)

      by mmogilvi ( 685746 )
      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.
    • You should thank the customer! Web apps are a nightmare.
  • SLANG (Score:4, Interesting)

    by goarilla ( 908067 ) on Thursday January 04, 2007 @11:20PM (#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 [] 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 (Score:5, Funny)

      by ColaMan ( 37550 ) on Thursday January 04, 2007 @11:36PM (#17469212) Journal
      Is that post of yours poetry? It almost could be, you know.
    • Re:SLANG (Score:5, Funny)

      by jbrader ( 697703 ) <> on Friday January 05, 2007 @12:45AM (#17469662)
      You are like the e e cummings of ./ posts.
      • 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.
    • 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.

    • by Sigma 7 ( 266129 )

      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

  • Try Charva (Score:2, Informative)

    by jpavel ( 129734 )
    Charva [] is an curses-based, Java text UI toolkit that is modeled after Swing. If you know Java and Swing, using Charva is quite straightforward, and won't require you to muck around writing your own text widgets.
  • Turbo Vision! (Score:3, Interesting)

    by pestilence669 ( 823950 ) on Thursday January 04, 2007 @11:26PM (#17469146)
    Borland's Turbo Vision UI was rather nice, considering it was all Text. It's even been ported for GNU toolsets: []

    Screenshot from the link of it on QNX: 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?
  • Lots of style points if you give them an old-fashioned Gopher intranet and Jughead search.
    • Wow, Gopher, Archie, Jughead and Veronica... I wonder whether anybody else knows what you are talking about!
      • 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.


  • Slang (Score:3, Informative)

    by John Hasler ( 414242 ) on Friday January 05, 2007 @12:06AM (#17469404) Homepage
    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

  • 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: ter/articles/introadffaces/index.html []

    Assuming it works, that is pretty cool, a
    • 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.
  • 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 t []

  • . . . 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 wh
    • 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.
      • by chinakow ( 83588 )
        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.
  • by Argon ( 6783 )
    When I saw this post on slashdot, the top Freshmeat item is coincidentally a python based Text UI library called . []
  • 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
  • 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 32
  • Home Page [] for eLinks.
  • 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
  • So, yeah. Looks like no-one has any better recommendations...and little to say that's constructive at all, for that matter.
  • 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.
    • 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.
  • Check this out : []

    Yep, the old turbo vision. Very useful, object oriented, shortcut keys built-in. Mouse handling, very fast, very well debugged. Great stuff
  • 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
  • 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
  • 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.
  • On OpenVMS?

    No, I'm not being facetious. It still works great. Especially over those serial connections. []
  • Now, I use vi, but you could run that would-be o/s emacs, and just fill it up with macros....

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

  • 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
    • by DrSkwid ( 118965 )
      You could also use a 9p enabled Linux kernel like Ubuntu and import the remote file system into your local file tree using v9fs []

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

"Remember, extremism in the nondefense of moderation is not a virtue." -- Peter Neumann, about usenet