Console and Desktop Shaking Hands
 by Dennis Heuer, in Editorials - Sat, Aug 7th 2004 00:00 UTC

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

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:

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?

Author's bio:

Dennis Heuer is a 34-year-old German social scientist concentrating on human-computer interaction (HCI) and e-learning.

T-Shirts and Fame!

We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

[Comments are disabled]

Referenced categories Topic :: Desktop Environment :: Gnome

Referenced projects D-BUS - A message bus system. HAL - A hardware abstraction layer. pkg-config - A package configuration system for compile/link flags.

 Comments

[»] For plugins too
by Gilbert Ramirez - Oct 14th 2004 11:16:42

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.

[reply] [top]

[»] Hmmmm...
by Kathryn Andersen - Sep 13th 2004 01:29:45

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 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.

--
Say it with flowers -- send a Triffid.

[reply] [top]

[»] Slightly different approach
by Sascha Demetrio - Aug 16th 2004 14:04:54

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 :)

[reply] [top]

[»] Console and desktop shaking hands
by Anderson Lizardo - Aug 13th 2004 13:48:30

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.

--
Anderson Lizardo

[reply] [top]

[»] Console and desktop shaking hands II
by garfycx - Aug 11th 2004 07:32:02

Because of heavy dispute I decided to write this second part. The dispute showed four types of comments:

1. what it's worth for?
2. doesn't work
3. can you give some alternatives
4. would love it

I will not answer to the first type because these people are just not target of my article. The comments of second type weren't always helpful. Some authors were just off topic. I think, I reach them more effectively by answering to the third type. The authors of the fourth type will love that too, I think.

My article crossed three main problems:

1. desktop and console are lacking interoperability
2. the console is not feasibly discovered and documented
3. console tools don't share internals in a computer-processible way

I discussed the problems in the order in that I discovered them. The comments, however, showed me that this didn't work out. The new approach is based on what was discussed most and how I think this is to be put in order.

Both the comments of second and third type argued about which side is to provide the computer-processible information to enable an automated integration of commandline tools (not only into desktops but also into apps like vi or mc). The graph of possiblilities ranged from highest decentralization (every tool a special parameter) to highest centralization (one single db located on the internet). Both ends of the graph seem to be only suboptimal.

The commandline parameter

Some argued that the developers of commandline tools will never support a new parameter. I still don't agree with them. If a parameter will be available in future is dependent on its sense and not on the number of tools. Most of today's usual parameters (-h,-v,-u,--enable,--disable,--with,--without, to list a few), parameter-styles (short and long form) and even options (yes/no/auto) have been spreaded by just copying them from other tools.

However, there is a crucial problem with the parameter --parameter-list proposed in the first part of this article. The problem is not related to the parameter itself but to the way of using it. There may exist commandline tools that start actions without checking for parameters. If a dialog tries to ask such a tool for its parameters it starts an unwished chain reaction of unknown dimension. I don't want to discuss about the dangerous product design of such tools. They may exist and that's why a dialog or application should not start unknown commandline tools to check for parameters.

I still see sense in optionally supporting the parameter. However, this should be based on the solution discussed further below.

The online-database

Centralized solutions first sound inviting but fade at second look. My critique is based on four arguments.

1. centralized solutions need full acceptance, otherwise they die out
2. the necessary 24h-availability doesn't only depend on the provider
3. keeping the database up to date is hard work for a single provider
4. providing the right version of information may need client-side knowledge as well

Some argued that such a database should be provided distributor-wise or desktop-wise. The companies or projects have the power to do this. However, xxx-wise alsways means incompatible and redundant work. Some pointed at the .desktop format. This would be enough for the dawn of a solution if it wasn't used desktop-wise only.

The distributors and desktop projects may sample, assort and distribute (parts of) the database. However, there should only be one installation per system, at appropriate place and accessible by all who want to. And, I don't think that console-interoperability should base on strategies unknown to the console.

The mixed approach

I tend to a well-tested organization model. The model splits the database into application-wise files and organizes them at typical places in the filesystem. The same strategy is used by man, info and other tools. I prefer it because

1. the model works very well
2. it works centralized as well as decentralized
3. reasonable desktop integration is possible, as being proofed
4. the question of distribution is solved for years now
5. all parties (distributors, projects, individual developers and users) accept the model
6. everybody is enabled to create, distribute, localize and use the information
7. administrators are enabled to organize the database system-dependent
8. the model can profit from an online-archive, CVS-like update and download features, etc.

There's the problem of finding a good place in the filesystem. I think that placing a new directory besides man and info and storing parameter descriptions in there is not enough. Drawing conclusions from the dispute, there is a need for a new, global and interdependent organization of application-relevant information. For example, a search dialog must be enabled to provide the user with

1. a catalog of relevant application
2. brief information to the selected application
3. ways to go deeper into the materies
4. the application parameters in a feasible manner
5. mime-based actions

Consequently, it would be reasonable to argue that parameter list, man page and other necessary resources must be reduced to just one, big XML document. I don't agree to this because different types of information should be kept separately to ease maintenance and future development.

However, there should be a root directory. For example, there could be a new directory named desc. Below that directory the parameters are found in params, catalog information is found in cat, desktop information is found in desktop, etc. As you can see, I don't believe in the way the desktops go today. They should open their resources and integrate them into a more general, system-wide (not system-dependent) database. If this is sorted subject-wise or app-wise is something to discuss about.

Most comments favourized XML for the formatting of the files. My only critique on XML is that I understand something different under human readable. The format should be easily convertable from XML to txt and back to support "normal" text editing. The concrete formats are a matter of the initiative working on this new approach. Considering the example in the first part, the parameter document could look like:

<apm version="0.1">
  <app name="GNOME-CD" type="media" class="player" keywords="CD,DVD" param_version="1.0">
    <title>
      GNOME-CD 2.8.1
    </title>
    <info>
      The CD Player application enables you to play audio Compact Discs (CDs) on your computer.
  </info>
    <category name="Information">
      <param name="--help" type="switch" title="short help" target="all">
        A brief parameter overview
      </param>
      <param name="--version" type="switch" title="version info" target="all">
        Display the version number
      </param>
    </category>
    <category name="Application">
      <param name="--device=" type="string" title="device" target="all">
        CD device to use
      </param>
      <param name="--unique" type="switch" title="concurrent play" target="all">
        Play the CD on startup
      </param>
      <param name="--play" type="switch" title="auto-play" target="all">
        Only start if there isn't a CD player running
      </param>
      <param name="--disable-sound" type="switch" title="ignore sound server" target="GNOME2">
        Disable sound server usage
      </param>
    </category>
    <category name="Development">
      <param name="--gdk-debug=" type="string" title="debug" target="GTK+2">
        GDK debugging flags to set
      </param>
      <param name="--gdk-no-debug=" type="string" title="debugging off" target="GTK+2">
        Debugging flags to unset
      </param>
    </category>
    <category name="Display">
      <param name="--disable-crash-dialog" type="switch" title="no alert dialog" target="GNOME2">
        Don't display the alert dialog if an error occurs
      </param>
    </category>
  </app>
</apm>

So far for now. Can't sum up every thought here. Maybe the discussion will go on.

[reply] [top]

[»] CLI standardization would add power
by trev - Aug 10th 2004 03:51:34

I agree with you assessment that providing a standard CLI interface would add a lot of power to the Linux. The method you propose is a good start however I would choose a slightly different way. Changing a large portion of CLI apps to support this is a fairly large amount of work. As such the design should be well thought out. I would propose the following:

Add a new option to commands that will identify what format you are using. Off the top of my head something on the order of:
command ---x1 <options>

This would identify this request as using the xml version 1 syntax for options (that follow). I am not proposing this as the system to use but as an example. Whatever system is used it should support multiple syntax versions to allow new versions to coexist (if required) as well as transparently support the existing commands (if not supported an error is thrown and the calling app knows the option syntax is not supported.

Next the syntax of the options/values/attributes needs to be carefully created. I suggest this form be XML as it provides a large amount of flexibility and is easily parsed. This way commands can provide all the information GUI and other command line programs would want.

Initially CLI programs would not even need to be changed but shell wrappers could be created to provide this functionality. The GUIs can then start using the CLI components right away. Eventually, if the interest is there then the CLI programs will likely internalize this as a standard option for performance improvements.

Work should be done with any groups currently looking to standardize CLI syntax as their standardized syntax could be expanded to include this method as well as this method would comply to their standardization.

A bonus of all of this is that the XML output will likely provide a clearer blueprint for the help option of the command thereby hopefully providing more a more complete and consistent (internal to the app and to other apps as well) help option.

You have some very good points but I think more effort should go into the design before we look to modify many CLI apps.

Hope this helps

Trev

[reply] [top]

[»] Taken from FreeDesktop xdg mailing list:
by garfycx - Aug 9th 2004 03:01:27

>There is already a project aiming at just this,
>http://eventuality.freedesktop.org , using DBUS. As a side note, what's
>proposed in article, using magic parameters, is pretty naive approach,
>having number of weak points, as knipknap already pointed out in
>comments on gnomedesktop.org (http://www.gnomedesktop.org/article.php?
>thold=-1&mode=nested&order=0&sid=1907)
>
>Cheers,
>Maciej
>

Sorry but kidnaps comment is naive because he just mixes up some grasped information without reflecting what he was writing. Your tip, eventuality, shows that you didn't reflect the article as well. A better tip would have been: http://www.systemstability.com/ccli.html

There is no similarity between eventuality and my approach because "Eventuality is designed to fully leverage on latest-and-greatest technologies in F/LOSS world, particularly D-BUS, Evolution Data Server, and GNotify. " and trying to substitute action-based systems like cron while my approach just wants to make existing console tools communicating about themselves to enable other apps (dialogs, midnight commander, nautilus, vi and other tools that provide a kind of console access) to integrate these tools. The difference is that eventuality relies on predefined "actions" (OO-commandlines) but my article focuses on how to integrate unknown but existing and still used commandline tools.

The more I discuss about the problem the more I see that people do not even want to see the problem because they see things from only their position, their project and their ivory tower. Eventuality, d-bus, gconf etc. are all future solutions not playing well with today's console tools. Console tools would have to support this future vision which means that the developers must do far more than they'd have to for my idea. So, what's the point about "not getting developers to support it". As I wrote, not every tool on earth must support it. And, most apps support "-h,--help" or "-v,--version" or "-u,--usage" in either way today. That not really all (100%) tools support these parameters doesn't mean anything. It's like not all archives support configure/make. However, more than 80% do, and you always find an alternative app using it.

The second possible approach is creating a database like an RDF-based system, as was mentioned at Footnotes.org. This would not be maintained by the developers themselves, pushing the work to the users or maintainers (distributors) who will never catch up if there's not a simple way of producing the db automatically. This is what my approach offers. My approach also offers the documentation of the parameters, not only the app type.

To make that absolutely clear now: My article is not just about future GNOME, it is about those situations where a user MUST find a dynamic solution or is left alone with writing an action or commandline somehow. I'm talking about when the user needs to select a commandline tool that may be registered somehow in a db but not to the extend that the user could just configure the attributes and make it run appropriately. You can try to provide him with an action-based script language or a more complex solution, you can try to support him with a functionally restricted registry, you can base on GNOME-apps only. But, if the user wants to access the console tools on his system, as they are given today and for the next years, what can he do then except starting the terminal? How can he make them work fine with, say, nautilus console (an often formulated wish)? How the user can select these tools from dialogs in an almost HIG-compliant way?

There was another person saying that "generating" the parameter text is complex. No, it isn't. It is the same complex as printing the help message (application --help).

Regards,
Dennis

[reply] [top]

[»] Use standards!
by Volodymyr M. Lisivka - Aug 9th 2004 02:27:29

There are already exists

Common Gateway Interface (CGI)
Multipurpose Internet Mail Extension (MIME)
XML-Remote Procedure Call (XML-RPC)
Simple Object Access Protocol (SOAP)
Web Services Description Language (WSDL)
Resource Description Framework (RDF)

just bring them together.

Why not describe command line or Web interface of the services in the RDF or WSDL instead of pathing existing programs? That is UNIX way.

[reply] [top]

[»] Re: Use standards!
by garfycx - Aug 9th 2004 03:09:59

Unix is what I'm talking about ;-)

[reply] [top]

---

[»] Cool idea, but missing the points
by Adam Hooper - Aug 8th 2004 20:04:00

There are two main points I think the author ignores:

1. The gnome-volume-properties capplet was *always* intended as a "placeholder" to simply prove that HAL/D-BUS/udev are actually functional. What's being nitpicked by an alarming number of people as an example of bad UI design is actually a result of *no UI design whatsoever* by a kernel-level hacker using Glade for the first time in his life to let fellow hackers appreciate his (fantastic) kernel-level work. Nobody treats that dialog as a finished product.

2. Running apps from the command-line is a distinctly "hacker" thing to do. In other words, the author's proposal of a system to GUI-fy the command-line is useful to nobody. The GNOME system's target audience *never* uses the Run dialog. And the kind of person who *would* know how to use the command-line and would find it much more efficient to run "app-name --help" than to go through a GUI. So this GUI-fied command-line system has no audience -- only people who start a couple of programs with it, say, "ooh, this is cool" and then turn happily back to the faster, more efficient -- and, let's face it, easier -- console.

Let's say I want to use the Run dialog to issue an "xset" command. "xset --help" is 58 lines long. Those 58 lines sometimes have multiple options *alongside* one another to save space. And that's not even a particularly complex application; imagine a dialog which exposes all the options in mplayer or xine!

Both of these problems have been solved in a better way than using a command-line system. I don't need to use xset directly because Applications -> Desktop Preferences -> Screen Resolution handles it for me. And I don't need to invoke a media player manually; all I do is double-click on the file I want to play.

GNOME is a document-based system: instead of focusing on applications, it focuses on documents. The GNOME 2.8 mime-type system makes this document-centering even more pronounced and useful.

[reply] [top]

[»] Sorry but you missed the point
by garfycx - Aug 9th 2004 03:10:24

1. It's not just about one dialog! The volume manager just sticked me to the problem.

2. Your Idea of using GNOME is what the ivory tower queens like Icaza are proposing and what the developer and techie user guilds like the GoneME-lovers are opponing. There's no single use-case.

3. It's not only about GNOME. And, its not about what the system usually does but what can be done if the unusual situation appears. I'm not talking about GNOME vs. Console, I'm talking about having a dialog, midnight commander, the often wished nautilus console, vi or similar that's providing me with some console-based access but letting me type in instead of click and select.

[reply] [top]

---

[»] Re: Sorry but you missed the point
by Pete Bessman - Aug 9th 2004 23:21:38

Stating that other dialogs perturbed you without stating what those dialogs are (and how they sinned) is unconstructive criticism at best. As for what I learned from the rest of your comments, apparently Miguel de Icaza is an "ivory tower queen," and you want "console based access" that lets you "type in instead of click and select"? I must be missing something, because de Icaza has very close to nothing to do with the Gnome UI, and consoles, by their very nature, are used via typing. I have no idea where you're going with this, and argumentum ad hominem isn't going to get you there any faster.

[reply] [top]

---

[»] From command line to desktop.
by Mike - Aug 8th 2004 12:54:12

Sounds like a lot of people have been thinking about
this from one angle or another. I created a simple
shell script piping a bunch of awk commands
together, that gradually crunches down the output of
ls into xml. The idea being that, together with rdf
metadata an interface can interpret the ls command
to, for example, provide a dynamic directory listing in
xhtml or whatever. I wrote a small server in tcl to
serve up the output of this script to a browser that
could xslt it into something useful. I'm sure similar
programs already exist.

Though my implementation is woefully inefficient, the
idea of having a marked-up command line could be
very useful, given the right meta-data. True,
individual apps could provide this output themselves
and maybe they will do something like this one day.
In the mean-time though, we can create our own
scripts/programs, metadata, style-sheets and apps
to integrate the desktop and the command line
better. I think doing this would restore the UNIX
philosophy to the desktop, allowing programs to pass
data to each other as text rather than through some
API. I firmly believe W3C standards are the key to
this. If you haven't already, I think you should create
a project for this.

--
-- Mike

[reply] [top]

[»] Common command-line interface
by JGentry - Aug 8th 2004 11:24:22

Sounds reasonable to me. It would be one piece of something bigger, which is developing common command-line interfaces for apps that do similiar things. I have a little rant about that:

http://www.systemstability.com/ccli.html

I really talk about avoiding GUI interfaces, but an interesting example of how CLI standardization could make GUI's better.

[reply] [top]

[»] Re: Netstatus dialog
by apeiron - Aug 8th 2004 08:33:22

Sure, there may be very few network device drivers on an OS like Linux (where one driver encapsulates all Ethernet devices, thus hiding the actual type of chip that one has), but virtually every other Unix system out there provides individual drivers for each chip type. And unless the GNOME team either writes an interface to these card types or creates a database (which will become outdated as more drivers are written), it will always lack the functionality that you desire.

[reply] [top]

[»] Re: Netstatus dialog
by garfycx - Aug 8th 2004 08:52:57

The dialog may print: (unknown) /dev/MyDriver

[reply] [top]

---

[»] Re: Netstatus dialog
by Jörg Sonnenberger - Aug 12th 2004 06:04:31


> The dialog may print:

>

> (unknown) /dev/MyDriver

Where did you get the (stupid) idea of /dev/MyDriver? There is no such thing in almost, if not all all UNIX like systems. Network interfaces are not character or block devices, they live in a namespace of there own.

I fully agree the original comment, that suggesting to use anything about the interface name is asking for portability problem. In fact, all versions of SMIT (the AIX adminstration tool) from 3.2.5 to 5L use the interface name and nobody I know of complained about it.

If you want to know which interface belongs to which physical device, never forget that a network interface doesn't have to be backed by a device either.

[reply] [top]

---

[»] Re: Netstatus dialog
by garfycx - Aug 12th 2004 06:42:23


> Where did you get the (stupid) idea of
> /dev/MyDriver? There is no such thing in
> almost, if not all all UNIX like
> systems. Network interfaces are not
> character or block devices, they live in
> a namespace of there own.

I fully agree that there are cases unknown to me. I just wanted to show that if the dialog doesn't know a registered name for the device it can print (unknown device) in combination with whatever is available. This way you get the original name on screen. The original name may always be shown besides the descriptive name. Being descriptive as far as it works was the aim of my example. Nothing else, calm down.

[reply] [top]

---

[»] some valid points...
by Reinout van Schouwen - Aug 8th 2004 05:31:17

You have some valid points, the volume manager doesn't deserve a beauty prize. But, where are the bugzilla references? I do assume you reported the issues you found...

[reply] [top]

[»] Re: some valid points...
by garfycx - Aug 8th 2004 08:19:23

I already got trouble because the dialog is only a design study in experimental stage. I think posting to bugzilla is too early, I wanna have discussed the idea of it all first before calling the dialog a bug.

[reply] [top]

---

[»] The discussion about the problem is the problem
by garfycx - Aug 8th 2004 01:24:54

As I can see now, geeks, gnomeheads and boneheads always just talk about themselves. I think Linux is a strength and we should integrate the available resources like the console tools. I don't think that every user wants bash scripts in result. I think he wants a dialog. Some may not like the dialog I've created but there can be a different one. The real point is that there are dummy users who may want to acess the console tools. They need a GUI and they need to use parameters. This is to be put together.

The below critiques are somewhat ahead of what's actually needed or useful. My proposal only needs the developer to include a small text. It's just a text print, if you didn't get it. The dialog parses it and creates a GUI on the fly. This is not 100% HIG but makes things possible that are otherwise not possible.

Some say that my way is not implementable. The same guys talk about global registries etc. (coming up just so, or what?). My Idea of a registry is that once parsed lists must not be parsed twice. Nothing else. The registry is not necessary otherwise.

Others write about existing file-classification systems. However, they only provide the user with information about the sense of an app. They don't provide him with the paramters necessary to actually start the app.

Some talk about wrappers. Wrappers are unperfect and incompatible. Compare a gnome-wrapper for wget with a gnome-wrapper for grep. Tell me, is this the way to go? My dialog may look like child's play but its always looking the same and quite nicely arranged. And, it's a default solution. There still can be wrappers. But, how a dialog like the volume manager can make use of them (even know them)?

I think, before you criticise you should re-think if you really want a solution. As somebody wrote below, he's not really aware of the problem. At Footnotes.org, gnomeists shouted out loud only because they don't like external people criticizing their desktop, or they hate dynamically layouted dialogs. They can find another mechanism. My god, not a problem. But, first, they should ask themselves if they really want to integrate the console tools. I think, they just want to lay the carpet over the console. Sorry, that's just elitarian. Maybe that's why I tend to ask console tool developers for integrating the parameter. Afterwards, maybe, the desktop snobs accept it as well.

[reply] [top]

[»] Computer-readable man pages
by Ilmari Heikkinen - Aug 7th 2004 22:08:49

I've been working on something related to this. Namely machine-readable descriptions of programs. The reason I was doing them was to abstract command-line arguments, and to automatically pipe commands together based on their input- and output-types.

E.g.

ccp some.pdf some.mp3 --args cbr, 64kbps, mono

expands to:

ps2ascii | text2wave | lame --cbr -b 64 -m m - -

Anyhow, I'm using external XML files, and it's a slight pain since if the command args change, the description file needs changing too. So I'm all for making it the responsibility of the commands themselves. Or at least packaged with the commands, like the man database.

This is what the XML files look like

[reply] [top]

[»] Do it the right way
by stefan - Aug 7th 2004 20:53:03

A few comments:

One main problem of the 'Volume-Manger' is: the textfields are too small. If you ever tried to scroll through multiple of these far too small boxes, you stop believing in their beauty. It's often seen in the MS-World and Linux should should stop copying trashy ideas from there, just because windows users are used to it.
As you can see, the maximize-button is already removed in the redmond-manner, to prevent users from making it more usable (and perhaps ugly).

If only the application is asked for it's parameters, and the user-parameters aren't preserved, but the user is using it repeatedly with the same parameters, he is forced to repeat his click-scroll-click-click-[enter text]-click-click rhythm over and over, getting an impression of the linux (gnome/ ...) way.
On the other hand: If parameters are stored, there needs to be a distinction: use stored params/ configure params.
And storage needs to be in perhaps different ways: netwide-configs, user-specific configs, machine-specific, user-and-machine-specific...
Perhaps thinking about internationalization should be done here again...

Which is the linux-way? How to make it right?
Linux is superior, because you can see anything behind the scene. If you want.
You have fine-granular access. We should strike out linux strengths and show how to use them. You need to know a few things to get linux power:
How to use man, apropos, info and google, to find out, which command to use how.
How to issue for example convert --help yourself.
How to save a command to a shellscript, make it executable, and put it into your path.
Not complicated shell-scripts, but how to use $1, and how to avoid $PATH - and filepath problems.
Optionally how to create a colored button on the desktop, linked to the script.

A unified wrapper getting it's job done will fail for two reasons:
Computers don't have intelligence, and don't have taste.
Have a look at kppp to see, what kind of job a good wrapper needs to handle.

Linux strengh is something to be proud of.
Give the people a helping hand, how to use it.
After a 30 min. tutorial, repeated two times, everybody is able to write a simple start-script and knows how to handle similar problems in future.
Let's avoid the 'nice-but-useless' GUI-pattern.
The people don't need a golden letter opener - they need a knife, made from steel.
my 6 ¢.

[reply] [top]

[»] Re: Do it the right way
by perane - Aug 8th 2004 17:36:01


> Linux strengh is something to be proud
> of. Give the people a helping hand, how
> to use it.

sure it is. but strength can definitely discourage.


> After a 30 min. tutorial, repeated two
> times, everybody is able to write a
> simple start-script and knows how to
> handle similar problems in future.

and he will ask: "why don't i get an easy dialog for this?"
or will think: "on a windows machine, this is much easier"
it's not that it will be impossible to write a shell script for that task just because there is a dialog ...

it's just a matter of choice, for those who don't want to write shell scripts. maybe due to missing computer experience.

you should always have in mind that a lot of average windows users don't know their progs remain on disk if they delete the link on the desktop. users like this may want / be forced to use linux. and believe me, these will not write shell scripts after reading 30 mins of online-help!

linux is for everyone, not just hobbyists, developers and powerusers.

most of the linux-newbies don't have any experience with UNIX and haven't seen a shell before.

don't expect too much.


> Let's avoid the 'nice-but-useless'
> GUI-pattern.

why?

because you don't like having a GUI for everything? maybe someone else does!


> The people don't need a golden letter
> opener - they need a knife, made from
> steel.

and some love to use a letter opener because it's made for opening letters, even if a knife could do the job much cleaner ..

kids, stay away from knifes and fire :-)

[reply] [top]

---

[»] Re: Do it the right way
by stefan - Aug 8th 2004 18:15:48


> most of the linux-newbies don't have any

> experience with UNIX and haven't seen a

> shell before.

I have visited some linux-newbie-forums, and if something doesn't work as they expect, they install from scratch (the usual windows-way).
If they install something, they allways reboot - used from windows.
Shall linux adapt to their expections?
People know how to setup a new network-card with redhat - which will not work with suse or debian or ... and the other way round, but they don't know ifconfig, lsmod and /etc/hosts.
Well - a unique interface shared by all distributions could make things more easy, and the distributions differ i.e. in where they place 'rc3.d' - throwing away all the (gui-)dialogs isn't a silver bullet.

To know about lsmod and modprobe will help by installing a new soundcard. To know about network-setup.sh will probably not.

But I now heared, that the basic-installation of 'suse X.y' doesn't install 'less'.
Now - why should norman newbie use less - he refuses the shell although?

When you try to help someone in the forum, and ask him to issue a 'ps | less' or something, he will complain 'less not found - how to install that'?

And why install less, ps, sed, bc, ls?

If you build a system for people, impregnated against technical stuff, you'll get them. And it's a process, which will feedback to the system. (see 'less').

Never seen a shell before, that means: it's high time, to get used to it!

And everybody is free to create a gui for a program, even the author of the program.
Or a automatic wrapper.
Or a wrapper, which needs to be customized from the programmer, or another interested person.

[reply] [top]

---

[»] it would be great..
by lorro - Aug 7th 2004 10:57:27

Been thinking about this from another aspect a while ago: creating a GUI from man pages. The problem is, however, that manpages don't have such a clear syntax that you think by looking at them. Standardizing features is something like standardizing man pages: a good thing that noone will follow. It is, however, possible to do the job incrementally: make it possible to modify the program's GUI while running it. Then post the modifications somewhere. It's like creating themes for your favourite media player.

[reply] [top]

[»] Re: it would be great..
by garfycx - Aug 8th 2004 00:55:58


> Been thinking about this from another

> aspect a while ago: creating a GUI from

> man pages. The problem is, however, that

> manpages don't have such a clear syntax

> that you think by looking at them.

> Standardizing features is something like

> standardizing man pages: a good thing

> that noone will follow. It is, however,

> possible to do the job incrementally:

> make it possible to modify the program's

> GUI while running it. Then post the

> modifications somewhere. It's like

> creating themes for your favourite media

> player.




Indeed, there can be some profile-db not depending on the app itself. Users can help out creating this. The only interesting thing on having the app protocolling its parameters is that the developer knows best about them and the list is always at hand, even if you use the app from command line. However, there are several opportunities...

[reply] [top]

---

[»] Might be a good idea as a general mechanism
by Guss - Aug 7th 2004 07:08:07

but why use all that heavy-handed stuff for the simple problem of choosing what program to use for a specific purpose ? you have the file associations mechanism which was built to handle exactly that !

When you install a software (for example - a video player), it "installs itself into the desktop" by adding itself to the file associations for the media it supports (by registering as the default - or one of the available applications - to use for playing video files). all you have to do now is to get the volume manager to actually use that handly already existing feature and offer - instead of a text box and a browse button - a list of the programs already registered to handle that type of media. I'm not sure how GNOME handles media types such as "dvd", "cd" or "blank cd", but it will be easy to add that.

The plus side is of course - you don't have to change all the apps in the world to make your desktop work.

[reply] [top]

[»] Re: Might be a good idea as a general mechanism
by garfycx - Aug 8th 2004 00:55:56

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.

[reply] [top]

---

[»] Re: Might be a good idea as a general mechanism
by matt - Aug 8th 2004 08:40:41


> 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.

I think it will be great if we could use this database in *priority* ... and for geeks, it could be possible to use the command line for the apps that don't use this database in an "advanced" panel that could be hidden or something (could be shown by pressing Ctrl-Shift-Tab-Caplock-A ... geeks (like me) love difficult things ;) ).

I know this idea is not perfect but it could be in that direction. I think the idea for the user to use the command line *only* in the settings is really bad.



[reply] [top]

---

[»] Re: Might be a good idea as a general mechanism
by Guss - Aug 12th 2004 12:55:30


> 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


[reply] [top]

---

[»] If I understand this correctly...
by Peter Amstutz - Aug 7th 2004 04:04:16

So what you're basically proposing is that command line programs provide a standardized way to print their command line options to stdout in a computer-readable format. Then GNOME can read in the command line parameter interface and use it to put up a slightly more helpful dialogue box for the user.

First, this requires modifying every application you might want to use through this system. That's a lot of programs, and good luck convincing people to do it. Second, command line interfaces tend to be more low-level than is useful for a GUI interface, so simply providing a list of the options doesn't actually make it any easier to use. Users who are comfortable with the command line can probably read the program's "-h" or "-?" output on their own just as easily. Users who don't understand how to use the command line probably won't understand the command line paramater description output, either. A more sophisticated wrapper around the program's functionality is usually called for in a GUI. Can this system provide that?

[reply] [top]

[»] Re: If I understand this correctly...
by garfycx - Aug 7th 2004 05:53:22


> Then GNOME
> can read in the command line parameter
> interface and use it to put up a
> slightly more helpful dialogue box for
> the user.

Slightly is quite understated...


> First, this requires modifying every
> application you might want to use
> through this system. That's a lot of
> programs, and good luck convincing
> people to do it.

I already answered this in the article. There is no need to enforce the move because the now actual way is still available. If the application provides such a list, fine. If not, fine.


> Second, command line
> interfaces tend to be more low-level
> than is useful for a GUI interface, so
> simply providing a list of the options
> doesn't actually make it any easier to
> use.

I proposed the category attribute. There could be categories that are ignored by the dialog.


> Users who are comfortable with the
> command line can probably read the
> program's "-h" or
> "-?" output on their own just
> as easily. Users who don't understand
> how to use the command line probably
> won't understand the command line
> paramater description output, either.

This is not of matter at all. First, there are quite many users who understand their system and want to see such information in the dialog. Second, every parameter description provides a "name" and a "tooltip", both free of choice. Further, there is the category attribute. This is quite enough to show the user if he is the one targetet at.


> A more sophisticated wrapper around the
> program's functionality is usually
> called for in a GUI. Can this system
> provide that?

I know a lot of such "sophisticated" wrappers and don't use one of them. Their GUIs are a mess, and they all work different. If this is "sophisticated" I stay with my "rudimentary" approach that unifies the output.

[reply] [top]

---

[»] Re: If I understand this correctly...
by Johan Maasing - Aug 7th 2004 13:35:23


> First, this requires modifying every

> application you might want to use

> through this system. That's a lot of

> programs, and good luck convincing

> people to do it. Second, command line

As a developer I probably don't know or care too much about this to change my applications, at least not until everyone else uses it. However, the brave souls that package applications for this and that system and distribution maintainers might be interested in actually providing the proposed command line options. It wouldn't be that hard to write wrappers (native executables or shell scripts) that provided the required options and translated them to whatever the application uses.



[reply] [top]

---

[»] Seams to be a good idea
by Raphael Zulliger - Aug 7th 2004 03:08:51

I think this is indeed something that should be added to command line apps & desktop systems (kde too of course).

moreover: wouldn't it be possible (or is there already something like that) to create a kind of (desktop independent) database, where apps may register itself. By registering they tell what kind of app it is, what kind of services it supports, a descriptive string, and so on. Of course then there must be predefined "services" and "application types". For example:

Known Services:
- cd_playback
- dvd_playback
- image_editing
- icon_editing
- ...

ok, the above names are not very well choosen... but something like that would probably help to search for the "correct" application to perform a specific task for a non-linux guru.

also this system probably wouldn't be aware of very special program-services - but that's no problem. If someone uses an application which does a quite special task, he will know anyway how to use it.

[reply] [top]

[»] Re: Seams to be a good idea
by Dark Liquid - Aug 7th 2004 04:09:14

Well 'apropos' and 'whatis' are kinda like that, a graphical frontend/replacement and with some more advanced searching functions would be useful as an alternate search tool for finding applications for performing tasks.

Of course, this relies on packagers of applications providing adequate man pages and what not, but a separate database would need maintaining from packagers too.

In addition to this, an online database could be set up, with all the basic info about various apps in a kind of wiki style system, then the database query program for searching for apps names and types can syncronise itself periodically (or at user request) with this online copy.

[reply] [top]

---

[»] Re: Seems to be a good idea
by Bruce Ingalls - Aug 7th 2004 04:14:12


> moreover: wouldn't it be possible (or is

> there already something like that) to

> create a kind of (desktop independent)

> database, where apps may register

> itself.


How about a --xml help switch?

The first parameter would tell where to find the DTD or schema.
This DTD can act as a registry, and can easily be upgraded. All help commands would be wrapped in XML tags, such as <tooltip>description</tooltip>, instead of a legacy ini file layout

--
http://emacro.sourceforge.net/

[reply] [top]

---

[»] Re: Seams to be a good idea
by garfycx - Aug 7th 2004 06:03:11


> moreover: wouldn't it be possible (or is

> there already something like that) to

> create a kind of (desktop independent)

> database, where apps may register

> itself.

I mentioned this in the article. Apropos and such are not the way to go I think. And, preparing all (given and future) applications to work with the online-database is waste of time. As I wrote, using a derivate of pkgconfig, the dialog can create the database "on the fly" and synchronize its local database with a database at FreeDesktop.org. This is more easy to implement and works quite automated. The user selects an application and clicks on the parameter button. The parameter dialog parses the parameter-list, displays it and stores the parsed information in its local database. By time, the parameter dialog tries to connect to the online-database for synchronization. So easy it is! In turn, the desktop can base on a dynamically updated application-database for i.e. the Search Tool or the "run command" dialog.




[reply] [top]

---

[»] Re: Seams [sic] to be a good idea
by Segers_J - Aug 7th 2004 12:29:10


>

> % moreover: wouldn't it be possible (or

> is

> % there already something like that) to

> % create a kind of (desktop

> independent)

> % database, where apps may register

> % itself.

>


> And, preparing all (given and future)

> applications to work with the

> online-database is waste of time. As I

> wrote, using a derivate of pkgconfig,

> the dialog can create the database "on

> the fly" and synchronize its local

> database with a database at

> FreeDesktop.org. This is more easy to

> implement and works quite automated. The

> user selects an application and clicks

> on the parameter button. The parameter

> dialog parses the parameter-list,

> displays it and stores the parsed

> information in its local database. By

> time, the parameter dialog tries to

> connect to the online-database for

> synchronization. So easy it is! In turn,

> the desktop can base on a dynamically

> updated application-database for i.e.

> the Search Tool or the "run command"

> dialog.

>

>

>

The magical part of this idea is that it distributes the work of creating the documentation the original poster asked for to any end user that is willing to take on any small part of the problem. To restate: Joe somebody wants to use program foo. Gnome runs it with the --version switch, looks on the online database, finds nothing. It automatically parses the SYNOPSIS section of the man page if it exists, then Gnome throws a "please help document this program" dialog, which has buttons/tabs to show the man and/or info pages. The end user then has the option of doing something to help without knowing how to write one line of code. Then, when you have already got the information collected, you can offer a service to the developers, giving them the option of incorporating that into their program in some useful way (maybe a --user-generated-preparsed-xml-help flag or something) Basically, I'm agreeing with the concept of "offload as much as possible from the developer so they can write and debug programs, not support yet another documentation style". Now, the question is how to moderate abuse without eating someone's time linearly with respect to the number of programs and versions thereof.

--
"forming and testing a theory can be faster than finding and consulting an expert" -- Jerry Segers, Jr.

[reply] [top]

---

[»] Re: Seams to be a good idea
by jef - Aug 7th 2004 12:50:06


> As I

> wrote, using a derivate of pkgconfig,

> the dialog can create the database "on

> the fly" and synchronize its local

> database with a database at

> FreeDesktop.org. This is more easy to

> implement and works quite automated. The

> user selects an application and clicks

> on the parameter button. The parameter

> dialog parses the parameter-list,

> displays it and stores the parsed

> information in its local database. By

> time, the parameter dialog tries to

> connect to the online-database for

> synchronization.

No sorry... no way.. no way is a model which requires people using systems inside an intranet to go outside into the wild to to retrieve information like this from a centralized server is going to be acceptable as an implementation goal. No way. You are getting WAY ahead of yourself by taking your thoughts this far without at least bringing this up in the development mailinglists of interest.
I would suggest getting your idea started as a thread on a freedeskop list that is relevant, or a gnome list. Your going to do your idea a disservice if you get too hung up on specific implementation details before the 'right' people get a chance to be sold the importance of addressing the problem raised in the article. Concentrate on selling the importance of cleaning this UI interface issues up, don't pick to sell a specific implementation to address them at the same time. In fact it would be best if you could offer several competing approaches to solving the same problem.

-jef

--
Elvis is dead...long live Elvis!

[reply] [top]

---

[»] Re: Seams [sic] to be a good idea
by Bruce Ingalls - Aug 7th 2004 16:44:48


> % the dialog can create the database "on the fly" and synchronize its local

> % database with a database at FreeDesktop.org.

>

> No sorry... no way.. no way is a model which requires people using systems

> inside an intranet to go outside into the wild to to retrieve information like

> this from a centralized server is going to be acceptable as an implementation

> -jef

It depends on what is being downloaded from the internet.
Simple unicode text may not be a problem. The rest could be certified and signed.


--
http://emacro.sourceforge.net/

[reply] [top]

---