Actions extensions in File Manager
faure at kde.org
Fri Dec 11 06:29:14 PST 2009
On Thursday 10 December 2009, Pierre Wieser wrote:
> Essentially, the spec says (see ) :
> 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
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:
(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
* 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
BTW, to see all the keys currently supported by KDE, see
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
More information about the xdg