Actions extensions in File Manager

[David Faure]

On Thursday 10 December 2009, Pierre Wieser wrote:
> Essentially, the spec says (see [7]) :
> a) you define a menu in a .directory file, with a label and an icon
> b) you define the order of the items, in a .menu xml file.
> This may not even need an extension of the spec, but rather a
> simplification to better suit our needs.
> 
> We would just have to carefully place our own files to no risk
> a collision with the global Applications menu.
> 
> But, eventually, yes, I agree that any spec is not complete while
> the menus are not described and properly managed. I'll work on
> this point.

I don't think it makes sense to confuse "the main desktop menu"
(as covered by the menu spec), and the popup menus of file managers.

I'm positive that we don't want any kind of XML for this, but rather something 
that can simply be done in desktop files. I don't exactly know what to suggest 
though, apart from taking a look a X-KDE-Submenu which I don't know in details 
myself.

Some comments on the proposed spec:

* Basenames defaults to '*.*' -- does that mean files without extensions
won't be matched? I think you meant '*' instead (this isn't Windows ;) ).

* Type=Application doesn't make sense IMHO in a desktop file that doesn't
have an Exec key (at the toplevel). It defines an application without defining 
it... Every existing desktop file validator and implementation won't like it. I 
think a new type should be defined for this spec, instead. (Selfishly I would 
say "Service" since that's what KDE uses, but anything else will be fine).
We use "Service" for any type of desktop file that is not a standard 
application definition, but e.g. plugins, or indeed such actions.

* "Valid schemes are those used by Nautilus" isn't very neutral in a spec ;)
I know that this is a much bigger problem (standardizing on scheme names),
but I think it makes more sense if we leave out this issue from this spec.
In fact the whole idea of listing schemes is not great, since one might want 
to say "all schemes that support showing directory listings", or "all local 
and pseudo-local scheme", or the opposite, "all remote protocols" (1) or "all 
protocols that support writing" (2), etc.
(1) we have this in KDE with X-KDE-Protocol=!file -- I suggest adding support 
for excluding protocols in your spec, at least, that one is easy.
(2) we have this in KDE with X-KDE-Require=Write

* Wildcard support for mimetypes is missing. Unlike applications (and their 
desktop entry spec). Examples:
k3b_create_audio_cd.desktop:MimeType=audio/*;
imageconverter.desktop:MimeType=image/*;
(since you use the MimeType key, remember that the desktop entry spec requires
a trailing semicolon...).
For efficiency reasons this is limited to <groupname>/* in KDE, so I think
a better model would actually be to use a separate key, like
MimeTypeGroup=image

* Dynamic presence checking is missing. The equivalent of X-KDE-ShowIfRunning
which allows for instance to only show "add to amarok playlist" if amarok is 
currently running. That's a simple check whether the list of registered dbus 
services contains the one specified there, easy to add.

* Dynamic actions are missing. E.g. the equivalent of X-KDE-GetActionMenu 
which contains the parameters of a dbus call. Example use case: showing svn-
related actions only in a directory which is a svn checkout.
This is currently implemented as
X-KDE-GetActionMenu=org.kde.kded /modules/ksvnd org.kde.ksvnd getActionMenu
which returns the list of actions, among those in the Actions key, that should 
be used. Which shows a good reason for keeping the support for multiple 
actions in a single desktop files, otherwise the same dbus call would be made 
many times...

BTW, to see all the keys currently supported by KDE, see
http://websvn.kde.org/trunk/KDE/kdelibs/kio/kio/kfileitemactions.cpp?view=markup

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).