Re: Applications instead of Commands

Fernando writes about improving the gnome-volume-manager capplet interface and I think everyone agrees that it’s needed - the current behaviour with asking for a command line is a bug. A severe one indeed. What I don’t like, however, is the suggestion of mixing MIME types into the picture.

When you look at it, what g-v-m provides is really a way to configure what your desktop does when certain system-wide events happen, while a MIME type is used to describe content, be that a message, file or whatever (sure, some of the heads on xdg@fd.o will disagree and say that MIME can used for anything). Whatever.

In the future I’m pretty sure we want to expand on what actions to take when system-wide events happen; for instance there should be some way of saying “Start Rhythmbox” or “Start JuK” when a music player is attached and I’m pretty sure we don’t want to invent a MIME type device/audio-player.

There’s also the “action” aspect involved; you want to do different things when a device is attached versus removed.

It looks to me like the best solution for this involves extending the fd.o desktop entry specification. One way of doing this would be to add appropriate sections

[System Action MediaAudioDiscInserted]
Exec=gnome-cd %f

[System Action MediaDVDDiscInserted]
Exec=totem %f

[System Action MediaPhotoMediaInserted]
Exec=nautilus %f

[System Action DeviceCameraInserted]
Exec=gthumb %h

Note that the %h parameter is the HAL UDI which is a unique ID representing the device; this is not needed for the Media* system actions. To get rid of the HAL dependency and provide interoperability with software not ported to HAL, this could be extended to

[System Action DeviceFooInserted]
ExecHAL=my-app --hal-udi %h
ExecDeviceFile=my-app --device-file %d
ExecPath=my-app --fs-path %f

and the launcher (e.g. g-v-m) would select the appropriate one. The order of the Exec lines would matter if more than one parameter is available.