Interoperability Between the GUI and the CLI?

shylock0 asks: "I use AutoCAD pretty extensively, and one of the things I've always loved about it is the fact that, in addition to having a GUI, it has a really great command line -- which you access simply by starting to type, and which will actually work alongside your mouse. CAD lends itself to this duality, mainly because its nice to be able to deal with the overall work visually, but be able to specify dimensions exactly. Having to use the mouse to click on a separate dimensioning tool-box for every element you create wastes a substantial amount of time. You can even use mouse and keyboard side-by-side, without clicking yourself into a different environment -- for instance, if you have selected an element, and are using the mouse to rotate it, starting to type commands to resize the object doesn't stop the mouse from being in rotation mode. Such functionality would allow complex tasks -- beyond just opening, saving, and so forth -- using direct keyboard input, but would work in the context of the GUI. For instance, it would be great if I could copy files from an open window just by starting to type 'copy'. What other apps, both commercial and free, still have an easy-to-enter command-line style element?"

"This seems to me to be a feature that would be great to have, particularly in operating systems and productivity apps. Once you get the hang of the commands, and assuming you can type quickly, keyboard input is actually faster than using the mouse. In AutoCAD, I can design an entire house using just the keyboard. How much productivity has been lost by the decline of keyboard use beyond simple shortcuts?"

Comments

KDE

[0x0d0a]

KDE has some sort of high-level messaging protocol so that one can send events, making it appear as if menu items were chosen and whatnot.

Not sure how concise the syntax is, but this allows command-line control of the app.

I can't wait until someone *finally* has a GUI, drag and point interface to setting up interapp messag sending. I mean a rapid development environment where I can choose a menu item, drag a little line to a button in another window, and have that button trigger said menu item.

Cocoa is fairly similar, but there's no free equivalent, and Cocoa, AFAIK, does not have a lot of work put into making it interact with the command line well, which would also be important.

CLIM

[__past__]

A lot of Lisp applications used to use CLIM, the Common Lisp Interface Manager. It integrates command line and GUI style interaction naturally - it is based around "presentations" of the objects in your program, i.e. whenever you "present" something as either text or an icon or whatnot, it remebers what it is, and the output can be used as input for other functions, be they called by name at the command line or, for example, as a menu entry.

The symbolics Lisp Machine user interface was based around this. For an impression of it looked like and worked, look at this movie. CLIM is available for the two major commercial Lisp implementations from Franz, Inc. and Xanalys; there is also a free implementation in the works. Here are some relevant links.

Learning Tool

[cpuffer_hammer]

Debase III had a "gui" that generated the commands at the bottom of the screen as you picked from the menus. You could also type into the command line. I learned a lot by watching the commands being formed as I made selections from the menu. As I learned I started typing more and more of the commands myself.

This might be a good way to introduce the GUI users to CLI by letting them see the relationship between the commands and the actions. Once they have seen how simple the command line is they may not feel as intimidated.

Charles Puffer

Re:Learning Tool

[Reziac]

I've previously suggested exactly such a tool for linux desktop configuration -- a GUI where one could make changes in (via checkboxes or whatever), that would simultaneously display exactly what change was being made in the actual config file, AND would allow the user to edit the actual file in the usual way for text. That way newbies can still have their hands held, yet they can learn what's going on under the hood. Meanwhile, old hands might decide to type in the config file side instead.

Ideally, such a tool might have a "novice mode" that makes the raw window "read only" so a newbie can't make stupid mistakes; and an "expert mode" which allows the user to do as they please in the raw window, and banish the GUI side if they don't want it.

BTW this is exactly how an HTML editor has to behave to be useful to me -- a WYSIWYG window where I do most of the work, and a raw HTML window where I do the tweaking. I want *both* available at all times, and preferably with realtime updates in both windows.

There is nothing as good for learning something as seeing how cause and effect are directly related. Plus it's a whole lot more interesting when you can SEE what you just did.

Quake (I, III & III) has this

[elliotj]

I've always loved the fact that hitting the tilde (~) key would bring a semi-transparent console down over the top half of the screen when playing Quake engine games. I think this is one of the smartest features of the product.

It has made me wonder why nobody has implemented this on an OS level. Mac OS X would be perfect for it for example. To just hit a key and have a console drop down from the top menu bar would rock. Frankly, if I had the programming skill, this would be the first thing I'd want to write.

I totally agree that CLI and GUI should be designed to work together. It really shouldn't be an 'either/or' consideration.

Entire House

[Mignon]

"In AutoCAD, I can design an entire house using just the keyboard."

Who needs AutoCAD? I did this in a Slashdot comment box. And best of all, it meets the Slashdot seal of approval, since it has no Windows!

/-----\
| _ |
| | | |
| | | |

Re:Konqueror

[TephX]

Well, I suppose it would have been, but I didn't know about it, and KDE has its own screensaver system (I'm not sure if it's embedding something else or what, but it has its own password dialog - it matches color schemes and fonts with your current KDE setup, which is a slight improvement, I suppose). If you're a programmer, though, and you use KDE, I'd encourage you to check out dcop. Granted, not everything (or even close to it) is scriptable at this point, but there are a fair number of functions you can get to - you're basically directly accessing the exported API of a program by this method. Type

dcop

for a list of programs you have running which provide a DCOP interface, then

dcop program

for a list of interfaces, and so on until you get down to the actual functions you can call.

Re:Konqueror

[JohnFluxx]

I've just played about for a minute and already found some really cool uses. I can modify my scripts that play music to do so in another session inside a konsole, and rename sessions:

dcop konsole-875 session-2 renameSession Hello

Or fancier,

dcop konsole-875 $(dcop konsole-875 konsole newSession) renameSession "Music"

hmm, not sure how you would then get a command to run in that session, but it's cool either way.

That's useful...

[Da VinMan]

...but the program has a reason for allowing you to do that. Quake, Autocad, etc. are examples of programs that are primarily visual and need a command line for finer grain tasks.

This requires the program in question to have an object model that the console can address. Otherwise, what will your command line do? It's currently possible to make a hotkey to bring up a command window anywhere in your current session, even in Windows. What's not commonly available though, is the ability for the command line to affect the currently running program meaningfully (like Quake does). What's even further away is the ability to control all applications from the command line consistently from anywhere in the OS. One application might only speak LISP, and the next will speak Lua, and the next might only "speak" ActiveX (where any ActiveX capable language can access it), etc.

So, the bottom line here is that it's virtually impossible to put this sort of thing together on an OS level, given today's technology. You could put together an "OS-wide" command line using today's technolgy, but you will not be able to leverage every program you use in that way.

I do agreee that CLI and GUI should go hand in hand, but the fact that they don't is mostly related to the corresponding cultures assuming that they can't work together. Note that I don't think the marriage of CLI and GUI are a technical problem; it's (once again) a cultural problem.

Not quite the same - close.. but interesting...

[MeerCat]

If anyone use Perforce (source code control) on Windows - the P4Win GUI client doesn't give you a command line, but it will show in a seperate pane all the "raw" commands it uses to drive the GUI, so if you want to know how to do something on the command line you simply do it in the GUI and then look at the log of how the program did it - very useful.

Similarly "Record a macro" in programs like Excel and Word will generate a (VBA) script of the function calls required to generate an action - again very useful for when you want to see how to do something programatically.

Finally, I always like the way that Emacs will intelligently use the status bar to report items like "you've been typing a long command but you've paused at this point", or some commands will display extra info (like - you could have done that with a keyboard shortcut), but these messages don't get in the way of what you're doing (like a modal message-box does). Oh, and recording actions to Lisp macros (cf Excel and VBA) is very useful too.

--
T