Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Technology

Interoperability Between the GUI and the CLI? 50

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

This discussion has been archived. No new comments can be posted.

Interoperability Between the GUI and the CLI?

Comments Filter:
  • KDE (Score:3, Interesting)

    by 0x0d0a ( 568518 ) on Monday January 06, 2003 @08:42AM (#5024465) Journal
    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.
    • Konqueror (Score:2, Informative)

      by TephX ( 54484 )
      Also, somewhat more directly in response to the question posed by the article, Konqueror can embed Konsole (the KDE terminal emulator) in a frame. When you switch directories in KDE's file browser, the terminal automatically does a "cd" to the new location. I've found this useful from time to time, although generally dragging and dropping directories or files from Konqueror to a separate Konsole instance has worked well for me.

      And the syntax for command-line control of KDE apps looks roughly like this (shooting from the hip, since I'm not near a KDE-running system at the moment):

      dcop KScreensaverIface lock

      (This would lock your screen, probably one of the more useful actions to be able to script.)
      • what xscreensaver-command -lock isn't good enough for ya? :)
        • Re:Konqueror (Score:3, Informative)

          by TephX ( 54484 )
          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.
          • Very interesting. Do you know if things like mozilla (i.e. non-kde programs) have any intention of support dcop? What does gnome do?
            • Re:Konqueror (Score:2, Informative)

              by TephX ( 54484 )
              Well, dcop is KDE's IPC mechanism, so I kind of doubt any non-KDE programs support it or will do so, although it should be theoretically possible... although for the particular case of Mozilla, if you just like its rendering (rather than the browser itself) then you can easily set Konqueror to embed Mozilla rather than khtml for its rendering component.

              To the best of my knowledge (and someone please correct me if I'm wrong here), Gnome doesn't have anything like dcop - kind of surprising, to me at least, given that Gnome is generally positioned as more developer-oriented. (By dcop in the previous sentence I specifically mean the command-line client; I'm pretty sure that Gnome does have some sort of IPC architecture.) I don't know if GTK+/Gnome are architected in such a way as to cleanly support something like this - the reason it's so easy to do in KDE is that QT keeps around a lot of information about the source at runtime, and dispatches things even more dynamically than normal C++ with RTTI (that is, it looks up functions by name and argument type, rather than just indexing into a vtable).

              I'm glad you were able to get some use out of it (as evidenced by your post below).
              • It would be a dream if gtk/gnome supported dcop and was compatible with kde, but by the sound of it that isn't easily possible at the moment.

          • Re:Konqueror (Score:3, Interesting)

            by JohnFluxx ( 413620 )
            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.

    • Re: KDE (Score:2, Informative)

      by Morth ( 322218 )

      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.


      AppleScript has a nice functionality.

      You start Script Editor, hit Record, then do your tasks, and whoops, a complete script... It won't be a button but well a menu item. The button can probably be gotten from some shareware.

      Granted the target application must support it, and it's sadly very uncommon.

      There used to be a shareware utility (probably spawned by the AppleScript functionality) that didn't have the support limitation, it tracked the mouse and keyboard events, which is somewhat weaker though as the setup must be exactly the same for it to work. Not sure if it has been ported to OS X or anywhere else, can't remember the name sorry.
  • and its clones, for many many years already
  • Microstation has it too. It has a lot of features that AutoCAD has (apparently, they're bumping heads in a few market niches). It's very easy to get to the command line, just like AutoCAD.
  • CLIM (Score:3, Informative)

    by __past__ ( 542467 ) on Monday January 06, 2003 @09:14AM (#5024601)
    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 [lemonodor.com]. CLIM is available for the two major commercial Lisp implementations from Franz, Inc. [franz.com] and Xanalys [lispworks.com]; there is also a free implementation [cliki.net] in the works. Here are some relevant links [cliki.net].

    • Of course, with everything from pixels (X), window managers, Object layers (GNOME) to Apps in
      a single lisp address space, you can avoid or work around more than one layer binding the same key.

      Have there been any developemts in seperate address space systems (X level?) to coordinate?

      Pop-up? Was this shortcut destined for the App, GNOME, wm, or X ?
  • Learning Tool (Score:3, Insightful)

    by cpuffer_hammer ( 31542 ) on Monday January 06, 2003 @09:26AM (#5024654) Homepage
    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
    • ----as a linux noob I can say I would love to see that feature. I keep a small console open but mostly I don't use it yet, and being able to see what's happening all the time would help (me at least) make the jump.
    • Re:Learning Tool (Score:3, Interesting)

      by Reziac ( 43301 )
      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.

  • by elliotj ( 519297 ) <slashdot.elliotjohnson@com> on Monday January 06, 2003 @09:49AM (#5024756) Homepage
    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.
    • 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.

      Not just the Quake games, but all games either based on them or influenced by them.

      I used to have great fun in Unreal, going to a particular level, turning on noclip and godmode, then spawning a load of characters and either fragging them silly or just go invisible and watch what they do on their own. Sometimes you could get different characters to duke it out with one another too.
    • Have yuou tried konquror,
      You can bring up a shell in the bottom of the file browser window.
    • That's useful... (Score:3, Insightful)

      by Da VinMan ( 7669 )
      ...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.
    • Wow, they should make a text editor that could do stuff like this too.

      Imagine, being able to go from editing text to, say, a command mode by pressing a key like (or `~' if you really wanted).

      Then you could do stuff like copy whole blocks of code to the clipboard by typing something like `yi{', and paste it with `p'. By adding some extra syntax to this, you could probably have a whole bunch of separate clipboards a couple of keystrokes away.

      More complex commands could be delimited by `:' and , (e.g. to load another file into a new window could be `:new filename').

      A simple extension to this (such as using `:!' to start), and you could enter shell commands as well! Imagine, being able to type `:! ls' from your text editor to get a directory listing without having to go to a separate window!

      And if dismissing the command window to go back to inserting text was just another keystroke away (such as `i', `a', `o', `O', or even something else), imagine the productivity benefits you could get! :)
  • Not quite what you mean, perhaps, but one of the great things about smit/smitty in AIX is that the GUI (or curses based version of it) is simply a frontend to the OS level commands. For example, "smit mkuser" brings up a dialog to set all the parameters for creating a user. Once you've run the command, you can use the "View command" option to see what was actually run.

    In a lot of cases, I'll use smit to do something, then repeat from the command line to run over multiple instances (e.g. to mirror multiple logical volumes).

    • Of course if IBM hadn't come up with a new, bizarre and prolific set of AIX-only commands, you wouldn't need SMIT.

      AIX is a very well thought out OS, but can become maddenly frustrating at times...
  • by grundy ( 151557 )
    DDD (a gui front for gdb) has this. I haven't used any other gui debuggers for a long time but I seem to remember M$ had something like this in theirs as well. You can use all the gdb commands in the command window, plus when you execute a gui action it will show you the command in the command window. Very helpful for weaning windows folks from the gui only mindset.
    • by irix ( 22687 )

      You can use all the gdb commands in the command window, plus when you execute a gui action it will show you the command in the command window.

      The debugger with Sun Workshop does the same thing. Sometimes I use the GUI as a "help" feature when I can't remember a command ;-)

  • There are quite a few 3D apps on the market that have good CLIs. Rhinoceros [rhino3d.com], Alias|Wavefront's Maya [aliaswavefront.com] (through MEL scripting), 3D Studio [discreet.com] (with MAX script) come to mind, but I'm sure there are others.

    There was a small app for MacOS 7.1 back in the day that would allow you to submit DOS style commands: mkdir, rename, copy, move. Basically an experiment in API calls. I haven't owned a mac since '94, so I don't really know if this little app still exists.

  • I have always liked the AutoCad environment...infact when working in other CAD or simlar environments that don't have it I am lost...
    I also wish such a thing existed under the various Windoe managers, Explorer, KDE, Gnome, etc where you could use the keyboard and the mouse inconjunction...what a great thing that would be...
    I can think of all sorts of inovative ways to to use this sort of functionality....

    Imagine in the command window...
    Rename (click a bunch of files in the dir listing) *.old
    • That's precisely the kind of functionality I was looking for when I submitted the comment. If a programmer were to come up with a file manager for windows that let me do that, I would pay good money for it. Alternitively, it a good Linux file manager came out with that sort of functionality, it would certainly be another huge reason to switch...
  • In Macintosh Programmers Workshop. It's not quite the same thing, though. It's a dialog box that presents you with a preferences page containing all the command line switches of a particular MPW tool.
  • You can interact with the command line after selecting which packages you want to install/update. The reason for this is that the GUI is a wrapper for comand line functionality. Instead of obscuring the command line it allows you to interact with it. It will even launch the terminal app and type commands in it if you prefer that.

    I have done a lot of graphics work and I must say that if photoshop and illustrator coudl do this I would be rather pleased. You get to the point where you know exactly what needs to be done, but is a PITA to go to Edit>Image>Curves and drag around a picture of a curve rather than feed it exact values in a console. I think any application where you perform consise operations on visual data would benefit from this approach.

    We should make up a buzzword for it. What about "Active GUI" or "Dynamic GUI"? Once it is established as a marketing word it may achieve popularity.
    • Why doesn't somebody do this for the Gimp? Seems to me you've already got the necessary APIs, etc, all exposed via ScriptFu, and the code for a CLI/terminal in GNU readline and GnomeTerminal.
      • If somebody did do that for GIMP, it would be a substantial incentive for graphics houses to switch to it from Photoshop or Illustrator. Especially if somebody comes up with a fast GIMP port for Windows...
        • IANAGA (graphic artist), but I think the one thing Gimp needs for professional use is better colourspace management. As a minimum, RGB and CMYK separations, and colour calibration support. Unfortunately, AIUI, the big-time commercial colour calibration systems (Pantone, etc) all cost $$$ to license, which doesn't exactly mix well with free software.

          I'd still like somebody to implement a command line interface for it, though, if only to make pixel-accurate positioning easier for e.g. web graphics or XMMS skin pixmaps.

          Oh, and Illustrator is vector, not raster based, isn't it? So it's not really a direct competitor with Gimp or Photoshop.
  • by Mignon ( 34109 ) <satan@programmer.net> on Monday January 06, 2003 @01:11PM (#5026100)
    "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!

    /-----\
    | _ |
    | | | |
    | | | |
  • by opiate ( 16005 )
    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 :-(
  • by MeerCat ( 5914 ) on Tuesday January 07, 2003 @10:27AM (#5032188) Homepage
    If anyone use Perforce [perforce.com] (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
  • XMLTerm [xmlterm.com] mixes the command line and XML hypertext. I find it an instersting concept.
  • Funny how the less productive AutoCAD drafters/designers would pick at the dozens of icons on their digitizing tablet overlay...and when not doing that at the menu sidebars. The fast ones would mostly pound the crap out of the keyboard with an occasional mouse movement. The slow ones loved their Compaq 386's, and the fast ones were on a waiting list for a Unix box (first Sparc 2's, then SGI Indy's)

Physician: One upon whom we set our hopes when ill and our dogs when well. -- Ambrose Bierce

Working...