An interface paradigm that combines a GraphicalUserInterface with a CommandLineInterface, often embedded as a subsection of the GUI.
Implemented by a number of applications and systems:
-
- What command line? (in MS Development Studio)
-
- I know what the author of this comment meant, but it doesn't belong here. Explanation: Visual Studio .NET 2003 comes with a bunch of command-line tools for tasks like generating your own PGP key, cryptographically signing an assembly, adding an assembly to the Global Assembly Cache, and converting COM components to .NET assemblies. However, these tools rely on some DOS environment settings, and Microsoft opted to kludge this with a "Visual Studio command line." It's really just a command line with some (many) extra environment parameters. Neither it nor the CLI tools have a GUI interface, and it doesn't belong in this list. I understand why the author made this mistake, though: VS.NET2K3 is *all* about the GUI IDE, so it's easy to presume that a bundled "VS command line" utility has some GUI ties. It doesn't, though. - David Stein/sfsdfd
-
- It does if you include the "CTRL-/" thing: the right of the two text entry box's on the gui. It's normally associated with Find -- type some text in and hit return and it will -- but you can also type commands in. A command is a bit of text that starts with ">" and then follows a format a bit like the menus. For example, typing ">Edit.Undo" and hitting return is the same as selecting Edit->Undo. It even has inteli-sense.
I used to use an ICE from Lauterbach that had a command line, with GUI buttons below it. The buttons would change to show legal options at that point on the command line. You could either type the commands or press the buttons, and the command would be built as you went. I have never seen another ICE interface that was simultaneously so flexible, powerful, and fast to use. -- DougKing
This is one way that IvTools augmented InterViews.
Even though we're not the first to try, let's figure this out:
The advantages of a GUI, such that a CLI is not always best:
- Less overhead to achieve baseline proficiency.
- Certain things can be said efficiently with a GUI. If you want to say, "That pixel right there," a mouse is often the best tool.
- The GUI lets you draw high resolution pictures (either the user or the system).
- ...
The advantages of a CLI, such that a GUI is not always best:
- Can be faster after you've gotten the hang of it. TabCompletion and spell-correction help speed even more.
- Easier transition to scripting. If you find yourself consistently executing the same five commands in a row, you could combine those into one. OnceAndOnlyOnceIsNotJustForCode.
- You can test through it. (AcceptanceTests)
- Can run it via telnet over slow dial in links (true CLI not the hybrid described at top of page)
- More generally, the amount of data transferred between user and computer (particularly from computer to user) is much lower.
- If you mean from client computer to server computer, it depends on implementation. All that really needs to be transferred is the mouse coordinates and clickstream. Client and server can maintain their own models of the GUI environment, like in a MMORPG. If you really meant between user and computer then you have a point. A "true" CLI is one-dimensional but GUIs have at least two.
- Type ahead. If you know a sequence of commands or menus you need to go through, you can type ahead of the prompts. Sometimes this is possible with GUIs too by clicking at the spots where the right buttons appear. But often it is not possible, especially with entries via keyboard because of different handling of the keyboard buffer. And it is also very fragile in a GUI too.
- Piping commands into each other has no real GUI equivalent.
Can we figure out ways to achieve the same benefits of both without having to create a hybrid?
Do you mean how can someone draw a graphic through a keyboard or how can someone enter command lines through a mouse or other pointer device? It is worthwhile to have plenty of crossover (mouse-based selection of command history, keyboard control of an on-screen cursor), but a keyboard and a pointer device can not be refactored into a single device. Therefore, if someone wants support for both commands and DirectManipulation they will need both of these aspects in their user interface, regardless of whether they are in separate windows or not.
I like it when programs can be run from command line completely separate from the gui, so it can be easily scripted if needed but still have the gui if doing it manually (and some people like doing it with command line even when running manually). Like ssh clients you can use gui or command line versions they do the same thing just different portals into the same process.
Note that autocad does not operate that way(external command line operations). The autocad command line and the dos/shell command line are not isomorphic. Be careful which terms are mixed.
I made the comment above before seeing the link below (which refers to AutoCad), so the musings above have nothing to do with AutoCad. I was expressing my general preference for software that has both options. A better example is new versions of windows trying to expose more network capabilities to scripting, to keep up with the competition from linux and bsd, so you don't have to do everything from the management console, and can script some of those functions with wsh. Having said that I think it would be better if the autocad (which I used to work with some time ago and am familiar with but not currently), command line was isomorphic with the dos/shell that would be applying OnceAndOnlyOnce .
Well, I'm not a big AutoCad user, but I know what you mean with the shell/gui integration. Back in the DOS days, Logitech had a program POPDOS where one could associate arbitrary commands and extensions. I even had a hacked-up powerglove running as the mouse driver. A wave of the hand could execute whatever was needed. Nowadays it has to be programmed, hacked into the registry, or is limited to just file extensions. I think a "Shell Studio" for windows would be very popular, the trick is how to do it flexibly.
GUI-ness of MacOsx Terminal:
- Drag and drop a file or folder icon onto a Terminal window to append its path to the command line. If the path contains spaces, they are properly escaped. This is probably Terminal's most amazing GUI interaction feature.
- Drag and drop text onto a Terminal window to append it to the command line.
- Copy and paste text with mouse selection and cmd-C/cmd-V, or the Copy/Paste menu items for you "mousy" menubar slowpokes, or the cntl-click popup menu for you clicky folks.
- Save all the text, or just mouse-selected text, in your Terminal window to a text file. The usual GUI "Save As" dialog appears, and you do your "Save As" thing.
- Print your Terminal text, or dump it to a PDF file, with the usual GUI "Print" dialog.
- This isn't especially GUI-ish but it's a cool trick that demonstrates Terminal's integration with the MacOsx system in general. Mouse highlight some text in the Terminal. Then make your way to the Terminal -> Services -> Speech -> Start Speaking Text menu item, and listen to your computer read your command line session to you. Weird.
- Search through the terminal's text.
- Simulate a double-click in CLI using the "open" command in Terminal. This is really powerful because it combines the simplicity of a mouse-click with the expressiveness of CLI. "open s*.doc", for example, simulates a double-click on all .doc files in a folder starting with s, opening them in whatever application is associated with .doc files. You can open anything from url's to folders in Finder like this.
- Windows can do all of these, except "Save As" and "Print". However, you can combine the clipboard functionality and another program to achieve the same. But Windows doesn't create PDFs, right? Not that a CLI session makes for a nice PDF... Windows can't create PDFs "out of the box", but you can get 3rd-party printer drivers for that purpose.
These items are frankly sort of pathetic, and consist of simple data transfer mostly from GUI to CLI or actions on selections. A true fusion of GUI and CLI concepts would be for commands that display filenames (such as find, ls, grep, and so on) to show manipulable mini-icons (or simply show as links), or to construct a command pipeline through subsequent clicks on icons representing pipe destinations (something like "drag and drop and drop and drop").Similarly, GUI file managers could do with CLI integration, at least by duplicating the feature set of the (Norton|Midnight) Commander apps (though not their precise interface). I wait in vain for such a tool to appear on any desktop in my lifetime.
Didn't OberonOperatingSystem work this way?
One good implementation is for the Perforce SCM tool GUI (circa 2008, at least; the last time this troper saw it in the wild). The bottom of the GUI had a command line. I believe that you could just enter commands into the CLI and use it that way. But I do remember that every time you ran a command from the GUI, it printed the command out in the CLI so that you could learn it for the next time.
This is similar to how recording AppleScript with Script Editor used to work (it still may, but I haven't done it in awhile). You would execute the action in the app's GUI, and the corresponding script commands would be inserted into the editor window. It was neat to watch, and often a good way to learn about the app's AppleScript dialect.
See TheInterfaceIsTheUserData
See CommandPattern for implementations that share the common code. You can have a GUI or a command line on top of this pattern.
CategoryUserInterface, CategoryCommandLine
Command Line Gui Combo