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.
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 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 (
aren't so many drivers that Netstatus couldn't provide dynamic,
HIG-compliant name resolution like the new MIME system.
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?)
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).
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.
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:
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).
version: version of the parameter list
All parameters must define the following attributes, in the given order
name: the parameter name to be displayed
// parameter-list start
name: concurrent play
name: ignore sound server
name: debugging off
[skipping the rest of the GTK+ parameters...]
name: no alert dialog
[skipping the rest of the GNOME2 parameters...]
// parameter-list end
The volume manager parses the parameter list and creates the
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?