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

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

OO and User Interfaces

[opiate]

When I was a kid in the early 80s and I read about "object orientation" and especially in reference to graphic user interfaces I really expected much more from them -- I remember my first encounters with Macintosh, Windows, Presentation Manager, etc. I was very disappointed. I was similarily disappointed years later when I finally got to play with the Smalltalk GUI that I had read about.

The only UI that impressed me was the Hypercard UI in combination with Hypertalk.

It has always seemed to me that there is such an incredible disjunction between the object-oriented infrastructure of some applications and the presentation they choose.

If things are truly object oriented, in the sense that objects are responding to messages and inheriting behaviours from each other, as a user of an application I ought to be able to send those messages. I also ought to be able to swap components out and visually replace them with other objects matching the same interface. I ought to be able to bring up a window and use a Smalltalk-style Inspector or Browser and visually see the relationship of objects in the application.

In an ideal world I ought also to be able to mouse over something, and bring up a _real_ "dialog box" and actually enter in messages for that object to invoke and see their responses. This seems similar to what the author of this slashdot submission was describing. (But to me it's less about "command line vs non-command line" as its about authors opening up the infrastructure of their apps for extension, scripting and inspection in general.)

But instead, GUI applications are really quite static, made out of prefab generic components. As an application author using an OO language I can't even use genuinely OO techniques with the GUI components: their implementation is frozen, you typically can't even really inherit from them (or if you can, you can't really change the visual implementation very much).

The only system that I've seen that defies this general trend is the Morphic graphics system in Squeak Smalltalk (but developed on Sun's Self project.) It's the only system I've seen that seems to focus on GUIs as environments (focused around objects) for exploration and customization rather than set, static applications where the focus is on "running the program" instead of on "using the objects."

Sometimes I feel we've made very little progress in the last 25 years :-(

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.