This Freshmeat article proposes a new technique for how desktops can integrate console applications.
Console and Desktop Shaking Hands
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I don’t understand, you always had the option to have a GUI app alter a prompt command….
That’s a terrible idea. Just plain terrible. That is quite possibly the craziest shit I’ve read all day, and I just read the ‘Groovy will rock your world!!’ article about 20 seconds ago.
That’s not a bad idea, but there’s always the issue of developers misusing these complex standards. We need something simpler. Actually, implementing getopts with meta-data extensions would be a more suitable idea than a document detailing some arcane standard.
One file, written in a suitable language, compiles to:
1. Configfile
2. Configfile frontend hints
3. Getops parser
4. Usage info
5. Manpages
Hackers love to solve multiple problems with the same code so this would be used.
The “Configfile frontend hints” is the new innovation here. This information would allow a configuration program to provide the user with helptext, config grouping, defaults, option validation, dropdown listst…
Feel free to implement, I’m lazy…
I think the bigger problem is that most GUI programs shouldn’t need a plethora of command line options. Most of the applications being launched from the Desktop shouldn’t need any command line options at all.
How often does any other desktop platform use command line arguments for applications.
Most of things could be wrapped in scripts and the user should be given a list of default scripts to call or an Other option if they really must run something wierd and complicated.
Take the idea from Dennis Heuerand combine this with the idea from John Nilsson-and put a twist on it
Have a system which stores all of the following:
1. Configfile
2. Configfile frontend hints
3. Getops parser
4. Usage info
5. Manpages
in a gconf-XML format-we don’t actually need to save this as “a” file-rather upon request all of the associated files-whether they are located in gconf itself or stored in /usr/share/blah would be queried and logically “present” as a file-a “metafile”. Only those files pertaing to the actual configuration need be located in gconf itself. Then create a set of dynamic parsing tools (XLST/Schemas) which re-present the stuff in these files(the “meta-file”) according to the task at hand- a configuration dialogue would be dynamically created by reading 1,2 and 3. Yelp would dynamically create -at install time -a help page based on the stored information in this format. Manpages would be created at install time by parsing the “meta-file”.
Hidden configuration options-options only available currently in gconf-could be rendered available to users dynamically. Pressing configure in an application would open up a new window which would display the Yelp help page -enhanced by reading and displaying the the full description of the corresponding gconf keys.
Part of this window would display the dialogue itself-each part hyperlinked to the enhanced Yelp help page-ie. click on a question mark and select one of the dialogue entries-the yelp browser quickly switches to the corresponding gconf key description field.
The dialogue itself would be created dynamically by reading the gconf keys and the command line options-which means changes in gconf or gnome-vfs etc. would dynamically be available to the dialogue. Any changes to the dialogue would then be stored in the gconf configuration and the associated .desktop file used to call the application.
The user would be prompted to name the new .desktop file and these in turn would be stored in the home direcotry of the user /.gnome2/application_shortcuts. These application shortcuts(mplayer-dvd) would be registered (MIME) and available upon clicking on the “browse” button-when choosing which application launch to in association with an action.
One would still be given the option to manually browse /usr/bin or kde/bin and choose what they want-but they would first be presented with a drop down list-accompanied by a short description of the already registered .desktop files. If they do choose a non-gnome application a new .desktop file would be created which contains the command line parameters of the non-Gnome application to be invoked-ie. the system would “learn”….
Perhaps a bit too crazy-but doable….;)
Your proposal is a little short sighted. There are times when a program fails to launch and developers might need information about the failing application. The command line is the only way to get information about the application such as it’s version number, the libraries it was compiled against, the compiler used to compile the program among other things.
In fact, sometimes, it is only through the shell that a user might probe the reason for the applications failure.(e.g segfault, misplaced lib files, etc). Most of the times I have needed support and assistance regarding a misbehaving app, the command line has been vital.
There are times friends and helpers have been able to connect to my machine and fix issues with apps, again via the shell. In an ideal environment applications will be designed for the shell and various front ends.
The front ends will be designed by UI experts or hackers to provide an elegant, simple and intuitive interface for general users. While the command line interface will exist for advanced users, developers and hackers.
This seperation is very useful because people could then design several front-end using their favorite tool kits. In fact, there are several programs in Linux that you can use from a shell, a GTK frontend, a QT frontend, an ncurse frontend.
The command line is not archaic. It is extremely useful and should be a part of the desktop, especially for system administrators. Heck as Unix users become more experienced, they should be encourage to use the shell and scripts.
Totally agree, CLI is important. The “2. Configfile frontend hints” should be equally usable by linuxconf as webmin as a qt/gtk frontend. Just the data needed to produce a valid configfile.
Instead of integrating the CLI into the desktop, we should investigate the possibilities of integrating the GUI into the CLI. Why do CLI windows use only text? We should leave the era of plain terminal-emulation behind and create a new, advanced kind of CLI.
The basic idea is that the GUI widgets we may need to represent our data should not appear in windows outside the CLI window (needlessly cluttering up the screen), but as part of the scrolling text that is “printed” as an answer to the commands you have typed into the command line.
The shell should maintain a vertical stack of GUI widgets, with a CommandLine widget at the bottom. The bottom of the widget stack should be always aligned with the bottom of the shell window (the scrollbar could be used to view the portions that have been scrolled out). When you type ‘ls’ into the CommandLine widget and press Enter, a FileListing widget would be inserted into the widget stack, right above the CommandLine widget. The FileListing widget may look like the result of an ordinary ‘ls’ shell command in bash, but you could right-click on the file/directory names and choose operations from pop-up menus, or you could SHIFT+click select list of files and associate them with shell variables which could be referenced in later commands given on the command line.
You could have several such widget stacks in one shell window, and you could cut/paste between the widgets…
Here is how an SQL query might work:
myquery = sql.query(“SELECT * FROM books WHERE title LIKE ?”)
myquery.exec(“compilers”)
and you would get the results of the query in a table widget, with its own scrollbar. Rows of the results could be selected, copied to clipboard and pasted to an e-mail composing widget in another session (or in the same session somewhere up in the stack).
I don’t claim that everything could be done in this way, but it could help us keep all the pieces of data that we are currently working on in one place (especially if we could bind all these data objects to shell variables and besides clicking on their GUIs directly in the shell window we could operate on them as variables in CLI commands).