Articles / Console and Desktop Shaking…

Console and Desktop Shaking Hands

The GNOME Desktop Environment is a dynamic, young project and full of expectations. I regret that mine are somewhat higher, though.

I was prompted to write by the list of what's new in GNOME 2.8. At first glance, this prospective gallery charmed my eyes and suggested the best interface quality and a pleasing user experience. However, the usual inconsistencies quickly caught my attention.

Simply elegant prematurity

GNOME is a very beautiful desktop, but when it comes to system integration, design and concept fall short. Most of the issue isn't covered at all, but even the integrated parts mature only slowly. The new GNOME Netstatus dialog unfortunately shows this tendency:

The new GNOME Netstatus dialog
The new GNOME Netstatus dialog

The first impression is very promising (though the progress bar is a bit thick). Only the connection name selector doesn't correspond to the GNOME Human Interface Guidelines (GNOME HIG 2.0). Instead of providing clear and descriptive terms, the driver names are just taken from the system's driver directory (/dev). There aren't so many drivers that Netstatus couldn't provide dynamic, HIG-compliant name resolution like the new MIME system.

Beautifying the command line

The most shocking example is the new GNOME Volume Manager. The GNOME Volume Manager "is a daemon designed to handle volume mounting and management under GNOME. Using the Hardware Abstraction Layer (HAL) and DBUS to communicate with the lower level system." (What's new in GNOME 2.8?)

The new GNOME Volume Manager
The new GNOME Volume Manager

Besides being already very old (I remember it being distributed with a GNOME 1.x release), even the new ingredients (HAL and D-BUS) can't render the dialog useful because the auto-start options, the reason for this dialog, must be entered manually in the form of a text console command.

I realize that providing a drop-down list of known applications would only throw a very small light on what the system usually offers. However, the average desktop user neither knows about commandline parameters nor even about the names of all the applications he uses because the GNOME naming schema (in menus and so forth) differs from the real application names (they're not localized, for example).

Inconsistent system access

Providing a browse button is just nonsense, too. One of GNOME's greatest aims is hiding the filesystem from the user. Consequently, how should he know where to search for an application for which he may not even know the real name? He could try a blind search. However, the file dialog neither supports searching nor provides a button for starting the Search Tool. Many of the dialogs that could make use of this button don't provide it, like the run command dialog.

Nevertheless, even the search tool is not appropriately prepared for this task. It just stupidly scans the whole filesystem for a given character string without understanding its own findings. This is very sad. If at least the default system resources, like the Filesystem Hierarchy Standard (FHS 2.0), the $PATH environment variable, or the distributor's metadatabases (rpm, deb) were considered to provide a somewhat more intelligent search, there could be something like a drop-down list of registered applications.

Coming back to the volume manager: Even if the application is found, it may need some "start" parameters. Unfortunately, there is no easy way to receive information about the available parameters and provide them in a more convenient way to the user. Ok, that's not GNOME's fault. However, because the problem has been known for years, GNOME could have worked out a solution already. I found a reasonably working solution in about two seconds.

Console and desktop shaking hands

Commandline tools like audio players provide a parameter to select the level of verbosity so that graphical tools are enabled to scan the output for user-relevant information like the song length. This technique could be used for scanning the available parameters, too. For example, applications could provide a global parameter for printing a protocol that describes the available parameters and how to use them. This is just like well-formatted application --help output.

I hear you saying: "How are we going to get all projects to support this, and on all platforms?" Well, why shouldn't they? And, if the global parameter is answered with an error, the dialog can switch back to simple mode, as is visible in the screenshot. It will work either way.

Here's one idea of how the handshake could work:

The user selects the GNOME CD player for when an audio CD is inserted. Immediately, the dialog starts the application to check its parameters:

gnome-cd --parameter-list

The application prints the following text:

GNOME gnome-cd 2.8.1
The CD Player application enables you to play audio Compact Discs (CDs) on your computer.

The below parameter list follows the Application Parameter Guidelines 0.1 (APG).
See http://www.freedesktop.org/specs/apg for more information. [Not really, please.]

Global attributes:

version: version of the parameter list
keywords: a list of common application classifiers
category: groups parameter definitions under a common label

Parameter-wise attributes:

All parameters must define the following attributes, in the given order
and followed by a carriage return. If the definition of an attribute
is too long for a single line, the following line must begin with a
plus sign (+).

name: the parameter name to be displayed
about: a small description usable for displaying a tooltip (max. 50 letters)
parameter: the parameter, including hyphens, etc. (e.g., --prefix=)
type: the expected data type, such as:
   switch: using the parameter switches the option to "on"
   string: a (double)quoted character string of arbitrary length
   digits: only digits from 0 to 9
   list [comma-separated list]: a comma-separated list of (given) strings
   [comma-separated list]: exactly one string from a given selection
target: the platform or application supporting the parameter

 

// parameter-list start

version: 1.0
keywords: audio-cd-player, audio-dvd-player

category: Information

name: help
about: A brief parameter overview
parameter: --help
type: switch
target: all

name: version
about: Display the version number
parameter: --version
type: switch
target: all

category: Application

name: device
about: CD device to use
parameter: --device=
type: string
target: all

name: concurrent play
about: Only start if there isn't a CD player running
parameter: --unique
type: switch
target: all

name: auto-play
about: Play the CD on startup
parameter: --play
type: switch
target: all

name: ignore sound server
about: Disable sound server usage
parameter: --disable-sound
type: switch
target: GNOME2

category: Development

name: debug
about: GDK debugging flags to set
parameter: --gdk-debug=
type: string
target: GTK+2

name: debugging off
about: Debugging flags to unset
parameter: --gdk-no-debug=
type: string
target: GTK+2

[skipping the rest of the GTK+ parameters...]

category: Display

name: no alert dialog
about: Don't display the alert dialog if an error occurs
parameter: --disable-crash-dialog
type: switch
target: GNOME2

[skipping the rest of the GNOME2 parameters...]

// parameter-list end

The volume manager parses the parameter list and creates the appropriate dialog:

The parameter dialog

There's a problem with the awful number of parameters an application can provide. However, the dialog can have a scrollbar, or can break into a second column when the dialog becomes greater than 80% of the display height, or whatever. This is up to the GNOME project. It only matters that dynamic dialogs work at about 90% GNOME HIG 2.0 compliance.

When the user submits the parameter dialog, the volume manager creates the commandline and asks the application to validate the syntax:

gnome-cd --check-parameters --play --unique

The application must provide useful error messages like:

-1: unknown parameter
-2: parameters incompatible
-3: value error
-4: unknown error

If possible, the application should also provide a descriptive, helpful error message. The dialog should always expect output. Perhaps the user configured things so that inserting a Zip disk starts a script that stores a backup on it and prints a status report to stdout. We should be ready for this.

That's it. It's not that much and it's not so different from what applications can do already. The implementation shouldn't be very horrible, even for other dialogs like the run command dialog. The implementation process will help with the discussion of good practices in defining commandline parameters. Using a derivate of pkgconfig, the dialog could even build a FreeDesktop Application Database. Ever thought about using day-by-day actions for (non-discriminatory) evaluation tasks?

The great advantage of this technique is that it just works. There is no complex protocol, no database, no XML. Applications can start supporting it whenever they like and to the extent they think is right. There's no need for changing the whole system environment at once.

What do you think?

Recent comments

14 Oct 2004 11:16 Avatar gilbertramirez

For plugins too
Your idea is beneficial to other things besides GUIs that wrap CLI programs. It's also beneficial to programs that are extensible via plugins. It's probably more benenficial if these programs have a GUI, but regardless, plugins are another class of things which need to publish the options they accept, and then receive those options from an outside program.

13 Sep 2004 01:29 Avatar kat

Hmmmm...
Coming in very late -- ah well.

I want to pick up on a comment which is somewhat to the side: the fact that in GNOME you can't browse commands and that they ought to be able to use things like $PATH to be more intelligent about it. I totally agree, which is one reason I use WMI (http://wmi.berlios.de/) and not GNOME. WMI wouldn't suit everyone, but if anyone wanted to say "Oh, it's too much work to have a dynamic list of commands based on $PATH", I'd point to WMI and say "It's already been done..."

As for standardization of command-line interfaces, what would probably help with that would be tools, stuff that helps self-documentation. One reason I like writing in Perl is the standard modules that help command-line parsing, and self-documentation -- just write the PoD in my file, use three particular modules, and I get man pages (ExtUtils::MakeMaker or Module::Build), HTML documentation (pod2html), and an easy --help option (pod2usage) for free!

Other systems could benefit from tools like that -- if they weren't too clunky and monolithic.

16 Aug 2004 14:04 Avatar gargamel

Slightly different approach
The idea of a standardized command line interface is pretty old, however nothing has been really agreed on. The big problem is to get a lot of people cooperating before things start working. I'd suggest a slightly different mechanism for invoking commandline tools from a GUI toolkit and/or environment:


1. Start with wrapper scripts for the commandline tools. These wrappers implement a standardized commandline interface and call the original programs. These wrapper scripts should reside in a special directory (e.g. $PREFIX/lib/ccli-bin/$PROGRAM).


2. When (if?) the CCLI standard is accepted by the masses, then the entries in the special directory will be replaced by links to the original command line programs.


This approach makes the transition easier, and the CCLI standard definition may evolve before the tool authors start adding support for it. The difficult part is to come up with a good CCLI standard.


A very important point is to provide a reference implementation. This includes a C version, Python and Tcl bindings, a pure Java implementation, ... A lot of work. Adding support for the CCLI to an existing program should be as easy as possible!


If somebody is willing start such a CCLI project, I might be willing to help (e.g. by doing some of the reference implementation work), so just ask :)

13 Aug 2004 13:48 Avatar lizardo

Console and desktop shaking hands
I think kaptain

(http://freshmeat.net/projects/kaptain/) can achieve

what your article suggests, without needing any

modifications to existing programs. You might want

to take a look on this project.

12 Aug 2004 12:55 Avatar Guss

Re: Might be a good idea as a general mechanism


> The problem here is that not all

> applications register at such a

> database. And, the idea above shall work

> for all apps, including their

> parameters.

Well - so, instead of fixing the few applications that do not register (something that can easily be done by the packager or even by the user herself), you suggest to change the code of all of the applications in the world (something which is lengthy and requires QA) ?

Yea - good choise

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.