Rapid Open Source Development for the Unix Console? 51
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."
I can't be the only one who (Score:5, Funny)
take web add lynx (Score:2)
lynx will give you that 'green screen' feeling.. and if you do the web right (no tables ) your pretty much there.
Re:take web add lynx (Score:3, Informative)
What this person wants to do is get over his leetness and learn to make a GUI application that behaves how he/she thinks a console app should work. There's no reason you can't bind keys the exact same way in a GUI that you would in a console app. And really, a console app created with s
Re:take web add lynx (Score:2)
What you are talking about has been done. Examples are vim, emacs, word, mozilla. Many programs have keyboard shortcuts. In fact the app that I work on for a living, has shortcuts, that are all modeled after the console app that they came from. So you can be just as fast. The problem is that he has probably run across the GUIs for kde and gnome and many of the unix GUIs that are out there, where keybord shortcuts are an after thought.
Re:take web add lynx (Score:4, Funny)
The problem with emacs is that everything but the keyboard shortcuts were an afterthought....
Re:take web add lynx (Score:2)
While the parent seems to have been more of a joke, some forms of keyboard shortcuts are available. You can use 'accesskey' for form elements. IIRC, links has implemented accesskey, but lynx hasn't.
for example <input accesskey="g" name="field g" type="text" />
Re:take web add lynx (Score:1)
PHP + Perl + Links (Score:5, Interesting)
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!):
Re:PHP + Perl + Links (Score:2)
In fact, I find that most of my GUI work is done using keyboard commands (Alt-D in a web browser is one of my greatest discoveries)
Re:PHP + Perl + Links (Score:4, Insightful)
But the point he was making is cogent none the less. If you go into the office and tell your staff they have to start using the apps. they've been using for years "the way you think they should be using them," you'll probably note the conversation around the water cooler goes silent as you approach for several months. And not in a good way. People usually need a motivation to re-train that is a little more upbeat than "because you're inexcusably slow."
If you have the tools to make the development cheap, a new app interface is a great approach to the problem. You get to have meetings, everyone gets their input, several features they've always wanted are added. They "buy in" to the new interface, and they all start at the same point when learning the new system.
In the case where the Linux developer is not the only smart person in the organization (it happens
Re:PHP + Perl + Links (Score:1)
Re:PHP + Perl + Links (Score:2)
Have you ever tried this?
Very few people's jobs are so quanitfiable that you can just look at some log file and figure out what their user-interface-operation speeds are. If you had something like a true data entry position, then it might be an option (and contests probably already exist at your office). For more typical office
Re:PHP + Perl + Links (Score:2)
Re:PHP + Perl + Links (Score:2)
Every once in a while you stumble across a reference like this and think to your self...why didn't I find out about this sooner. I guess I never though about it but thanks for the shortcut.
Re:PHP + Perl + Links (Score:1)
--Jason
Re:PHP + Perl + Links (Score:2)
Re:PHP + Perl + Links (Score:2)
Furthermore, the mouse isn't neccesarily the problem. The problem is that one has to switch between the mouse and the keyboard, the real slower-downer. With an OS that properly supports a mouse/pen-based interface and was designed well for that purpose, one could work just as fast. Take the NewtonOS, for example... No, one can't write quite as fast as one can type (I get 40-50 WPM with the Newton OS 2.1 HWR and 70 WPM typing), but it is very
Get a Mac! (Score:2)
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 [slashdot.org].
Re:Get a Mac! (Score:2, Informative)
Actually, this isn't far off...
Project Builder does have templates for console applications, and if you don't use cocoa (IE, stick to libc and posix libs) the resulting code is quite portable to a regular unix system (although you'll have to write your own makefile).
The best part about it is that PB can be extended with new templates, including console program templates. I'm sure someone out there [google.com] has already created a few and released them as a free download. You may need to spend some time developin
Re:Get a Mac! (Score:1)
Sure, but what he's asking for is a featureful toolkit. Writing console apps with Cocoa and PB is precisely what I had in mind, but he wants an open source kit, and giving up Cocoa puts him back in the libc boat. Albeit with a great IDE.
at my work (Score:2)
turbovision (Score:4, Informative)
Big words... (Score:5, Funny)
Not a UI issue, but design issue (Score:3, Insightful)
Re:Not a UI issue, but design issue (Score:4, Insightful)
Gui doesn't suck, gui design does. (Score:4, Insightful)
Re:Gui doesn't suck, gui design does. (Score:5, Interesting)
I think GUIs take a lot more effort and time to do well than most people will admit. This is one reason the UNIX CLI is still around (it's quick, it's dirty, but it works reasonably well).
Mainstream GUIs often have these problems: the fonts tend to be small making them hard on the eyes, grey and white backgrounds with black text are hard on the eyes, there tends to be more information packed into one screen often requiring scrolling (time consuming and hard on the eyes), GUI layout managers are mastered by few leaving some pretty darn ulgy forms (again, hard on the eyes), many GUIs imply the mouse for intuitive navigation, etc.
It also doesn't help that GUIs are enormous programs, which are inherently unreliable and often not predictable. One reason Windows gets such a bad rap is that Microsoft produced a huge program in about 1% of the time it should have taken if they wanted to do it well.
GUI's rarely support type-ahead (Score:4, Interesting)
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.
Interface (Score:4, Insightful)
Re:Interface (Score:2)
Learning how an application work depends 100% on consistency of how the application performs. I'm going to bring up Vim here (and windows as well).
Eg: From bash:
wget http://www.slashdot.org/
vim index.html
Speed vs Training (Score:5, Interesting)
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.
Old skool case tools... (Score:3, Informative)
Oracle forms [oracle.com]
Adabas Natural [adabasnatural4ever.com]
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.
Re:Old skool case tools... (Score:2)
Oracle Designer/Developer is pretty darn cool. You can design your application, then automagically build the same app for a console (like a VT100 or something), a Windows or Motif application, or a web site. In some cases, it can even import a VB app (or at least, all the forms) into its internal format, then generate a web site or a Motif app from it. Not the cheapest, but certainly one of the best RAD tools.
Re:Old skool case tools... (Score:2)
GUIs not necessarily slower than console apps (Score:3, Interesting)
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.
Re:GUIs not necessarily slower than console apps (Score:2)
GUIs can be fast too (Score:3, Insightful)
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.
Good question (Score:3, Interesting)
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 [invisible-island.net]. 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.
Re:Zim (Score:1)
404 page not found.....
Why need an IDE for console? (Score:2)
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 FreeB
Curses (Score:2)
sure (Score:2)
argc, argv and a case statement
When you're comfortable weilding that hammer... (Score:2)
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 th
Dumbest question ever!!!!! (Score:2)
Do your own research!