Slashdot Mirror
Rapid Open Source Development for the Unix Console?
Adam Weiss asks: "With Web Interfaces and GUIs being all the rage these days, it seems hard to find much about console application development. Web Interfaces and GUIs look pretty and impress people, but I've noticed that it's awfully hard to beat the speed of a well trained operator on a well designed console interface. Some of the HR folks at work use a console app to access employee records while others use a Windows GUI. The console folk can lookup and update three records in the time it takes the the GUI folk to clicky-clicky through one. So, are there any mature Open Source toolkits that would enable rapid development of console applications. Sure, there's curses, but that's low level pain in the arse. I'm talking like something that is specifically designed for building database applications- kinda like an extensible version of Microsoft Access Forms for the green screen. Something that's pretty easy for the simple stuff, but lets you break out and get complicated if you need to. (unlike Access) I know there's gotta be plenty of obsolete commercial stuff that makes these kinds of projects easy. I just want to know if there are any Open Source alternatives that are somewhat modern and well maintained."
misread the title as "Rabid open source development"...
lynx will give you that 'green screen' feeling.. and if you do the web right (no tables ) your pretty much there.
Only 'flamers' flame!
Links is a text-based web browser - building a console interface can be very simple using HTML and Links - you don't have to play with ncurses' mess.
The problem with GUI speed is not so much caused by design - it's the darn mouse that slows down everything... instead of doing a simple Ctrl-S to save, it's all these 6 steps (or more!):
Oh, right, open source. GNUstep might be useful. And you can use Qt without creating a GUI, right? That would offer a terrific source of powerful objects -- see this JE.
What I'm listening to now on Pandora...
we used to print labels through an as400 using rumba as our client to it... you speed through labels in no time flat however you couldnt preview what you were going to print. they updated us to a point and clicky interface that was supposed to help us by letting us see what we are going to print before it comes out. well it ended up being the same situation as before, you cant realy tell what's coming out in advance and the new point and click interface just slows us pros down. however, i must admit the learning curve for new employee's is much smaller.
-- botsex is {grep;touch;strip;unzip;head;mount}
Get Visual basic for dos and run it through dosemu :)
Turbovision was an old Borland library for DOS, with C and Pascal bindings, which addressed the niche you're looking for. There's supposedly a free port to Unix. I can't vouch for it personally, but check out this Freshmeat project page.
But my grandest creation, as history will tell,
Was Firefrorefiddle, the Fiend of the Fell.
I will never understand why people feel the need to use big words just to make themselves sound smarter. Case in point, saying "Rapid Open Source Development for the Unix Console" when what they really mean is "Perl".
Do the gui users have to point and click? It should be a pretty trivial task to make the gui useable point and click and keyboard navigable.
If the same amount of time and effort was spent making the gui ergonomic and "keyboard accessible", I suspect that you would find that their speeds were about equivalent.
A long time ago I read a book called "About Face." It was a book on user interface design by the guy who created Visual Basic (I think). Now don't discredit the book because its associated with a VB guy. From what I remember there weren't any code samples it was all theory. Basically it was talking about all the things your average GUI programmer was doing wrong back then. One idea that stuck in my head was that often people make the mistake of writing one screen to both view/edit and input data. The idea was that data input screens need to be designed for speed and efficiency but this layout is ugly and cumbersome when trying to view or edit a record. A manager of a data entry department at a local company in cincy said that everytime his people have to take their hands away from the keyboard and use the mouse he loses 3 seconds. So if you design a GUI screen that doesn't require the mouse, has lots of short cut keys and other conveniences like auto tabbing to the next field when the current field reaches the required amount of characters you should be able to achieve just as much throughput as a console app.
In Republican America phones tap you.
Web Interfaces and GUIs look pretty and impress people, but I've noticed that it's awfully hard to beat the speed of a well trained operator on a well designed console interface
The key phrase here is a well trained operator. GUIs are pretty, and can be slow, but almost anyone can plop their butts down and start working on it immediately. Console apps, fast as they are, require sometimes days of training before working on it, then weeks (or months) of experience before getting truely fast at it.
This tradeoff is what businesses look for, and if its a spot with a high turnover ratio, they don't want to throw money away on training. Sometimes its just better to make it more user friendly than speedy.
I just wanted that point to come across for why companies go for web design. Right now I'm putting a J2EE front-end on a mainframe backend for a company to trade a 2 week training class to a 1 day relaxed training class to operate the software. It is something where speed is desirable, but web speed isn't that slow for the internal app.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
The Informix 4gl environment. x4gl is pretty common there's even a GPL version Aubit
Oracle forms
Adabas Natural
I worked for a number of years developing case tools. I saw the tools used to great effect and also saw complete disasters caused by them. As long as you work within the confines of the tool everything will be quick and robust. Try and get clever and you might as well not use a case tool. The important word is TOOL not CASE.
A well-designed GUI app is not necessarily less efficient to use than a well-designed console app. The problem is that many GUI apps, especially custom-written apps or vertical apps, are based on the horrible "forms" or "screens" paradigm, where the app is just a series of screens, each with lots of fields. (And all web-based apps are like this so I also classify them as "horrible", despite (or maybe because) the fact that I currently write web-based apps for a living (because that's what people like to pay for).)
In fact, given talented UI (GUI or console) designers and application developers, I'd guess that a GUI app could be more efficient to use than a console app at least 75% of the time.
And of course, a well-designed GUI app should be easier to learn than a console app almost 100% of the time.
I know other people have said it, but let me give more concrete examples.
Keys can be associated with every field on the screen. The convention is to mark those keys with an underscore (prefacing the desired key with '&' in the label definition on most GUI systems), and CTRL-thatkey will jump to that box.
Reasonable default values are another key to console-app speed, and there's absolutely no reason why they can't show up in GUI apps either. In fact it's almost exactly the same amount of work.
The GUI has other advantages over console use as well, because of the wider array of widgets you can use. A notebook tab interface is easy to write in a GUI, but I doubt many console libraries make it quite as easy. (There may be isolated counterexamples.) Tab navigation is usually as easy as a keypress, CTRL-PgUp (mozilla) or CTRL-Tab (wxWindows tab control, some exceptions in wxGTK if certain widgets are included in a tab that might eat the CTRL-Tab) for instance. The ability to embed things into the GUI display might be useful.
I'd suggest going GUI and just being very methodical about making shortcuts for everything (and showing them on the screen).
Failing that, if you have time to learn it I'd suggest building the app in Emacs, or at least looking at it, along with the Lynx+web suggestions I've seen.
This is actually a pretty good Ask Slashdot, for a change.
I know exactly what you want -- something like a text-based Hypercard...a front-end building toolkit. Also, the insight that computer operators tend to be significantly faster with text-based UIs is interesting.
Suggestions have included text-based web browsers (not really ideal...I think what the guy's thinking of is a screen-by-screen interface where there's no scrolling or anything, much like those custom DOS apps that banks use) and perl (AFAIK, perl will let you enter lines but doesn't natively have a great text-based UI tookit). I don't think any of these are really appropriate.
You may want to look at dialog. It's a GPLed higher-level toolkit that sits on ncurses that ships with (at least) Red Hat. This is probably simpler than what you want, though, and I don't believe it has a drag-and-drop-ish interface. That means you can't "draw" the forms, like you can with common GUI tools.
Another package, which is probably about as powerful as what you want, is newt (ships with RH and made by them, don't have an URL). The problem is that while this is a relatively high-level widget interface, it *still* isn't to the point of drawing your interface -- it requires coding. It's LGPLed.
May we never see th
It's not open source but it's not a bad tool.. kind of a VB for the console (as well as a Windows version).
e nt .html
http://www.zimismobile.com/wireless/zimdevelopm
The whole pleasure of programming in console is doing it in your text editor, and compiling it on the shell by typing make. Theres RHIDE, and EMACS does fancy compiling, but nothing beats the simplicity of joe editor + bash command line.
As for curses, try ncurses. Ive been wanting a simple replacement for these, but I suppose getting used to ncurses and working with sleepycat databasen is the way to go. Need bigger databases?? Go with Postgresql, but build a good stable foundation underneath with FreeBSD or a stable linux kernel and glibc.
I still second your claim that someone on the command line (I think here you mean text mode GUI not command line) could work faster. A well designed GUI and a person used to it can work faster than any command liner. Fewer keys to press.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
You can build the apps you want to build with the curses libraries in a number of different languages.
Conformity is the jailer of freedom and enemy of growth. -JFK
That is, a continuous input stream that fills into the screens as they return data.
Go watch a few good travel agents sometime. They start their query, know what options are on successive screens, and are entering their choices before the screens even draw. Having seen those screens ten thousand times they have them memorized.
So, there might be 5 navigation steps to get to a desired screen but they don't see those 5 screens, they enter the navigation keypresses all while the second screen is drawing, which immediately is cleared as the next is drawn, etc, even if that stream is some weird string like 'R,N,1,3,F9'.
Now, one may argue that a good GUI would eliminate all those navigation steps by placing all the options on one, more dense, higher resolution, screen. Yet, in a complex system, not every element can be crammed on one screen, so there is still navigation that needs to be done, and the lack of type-ahead comes back to be a problem. Also, on an infinitely large screen the user takes an infinitely large amount of time to acquire his target, so every useful system of any complexity has to be multi-level.
There's also the issue of the keyboard being a much faster means of data entry than a mouse for certain types of data.
Plus, most terminals are of very low complexity and can be implemented to draw just as fast as their line speed allows. This compares favorably with, say, a web page full of DHTML, JS, CSS, and applets. Even a plain-old-html page often renders more slowly today because the browsers have to be capible of rendering so much more they're built on far more complex object models, which take time to process.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
these are pretty rapid in c/c++/fortran already...
;)
argc, argv and a case statement
Or use w3m, or if you want to be retro-cool, lynx. Whatever. Every good Unix nerd knows that every good site will work perfectly fine in a text browser, and this is a perfect example of such an opportunity: if all you want is a forms driven enterprise application, people have been moving these things to the web for years now, and there are huge, well tested toolkits for doing this in every language you could ever want to use (Perl / mod_perl, Python / Zope ...others too, or so I've heard -- something about Java or something).
Among other benefits, writing your network console app this way lets your developers leverage web & database skills that they've already mastered over the past few years, and your users can either have the console mode interface or if GUIs are that important to them they can use a standard graphical browser instead: no decision is imposed on them (well, aside from the snarky login script :).
I still like console apps, and don't mean to disparage them -- my main mail client, for example, is still Pine, and I wouldn't feel nearly as productive with any of the GUI mail clients I've tried (many of them). At the same time, I also wouldn't feel as productive in a web based mail client -- too clunky in the best case, and almost always a disaster in a text browser. Obviously there is a sweet spot to be hit and some applications don't work well through a web browser.
But for a lot of the network applications I've seen (the DOS based inventory lookup software in retail stores, etc) where the client is essentially dumb and all you're doing is the more equivalent of "SELECT Product FROM InventoryTable WHERE ProductID LIKE "%whatever%", that works very well in a Perl or mod_perl CGI/DBI script, and there's no reason that such a script can't be engineered to be just as easy to use in a good quality text browser like links.
If I were writing a network aware console app today, I would strongly consider such an implementation. There are cons -- it can be clunky compared to a pure console app -- but the pros are interesting enough -- interface flexibility, leveraging of well-honed skills, etc -- that it just might be the right approach in many situations.
DO NOT LEAVE IT IS NOT REAL
I know that you are looking for an open source solution, but let me recomend a commercial environment -- Progress databse.
If you are looking for something like Ms Access, progress is the perfect environment. It has a built in 4gl that is easier to learn than any that I have ever used before. There is a large user base and several ERP systems were written in progress. The further advantage of progress is that the GUI client makes it easy for your console application to run in a windowing environment.
Other features: sql, odbc, and a gui design tool.
Do your own research!
Religion is a gateway psychosis. -- Dave Foley