Actions extensions in File Manager

[Pierre Wieser]

Sorry for double post, due to wrong mail address.

----- "David Faure" <faure at kde.org> wrote:

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

Humm.. Why not ? These are just menus, don't they ?
Though I'd rather agree with your opinion below, I don't understand
the difference you do here ?

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

This may be a sort of variation of a .desktop file. I should be able to
write some proposition.

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

And actually coded default is just '*' - just a typo here.

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

What about 'Type=Action' ?
Is even a Type mandatory ? As we derive more and more from the initial
spec, I wonder what will be the usage of this key..

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

Yes, not ideal, I agree.
At least extracting a scheme from an uri is rather well defined.
I find your two points great. Do you have some sort of algorythm to
find properties of a given protocol ?

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

Another typo here :(
Of course, wildcards and list should be accepted.
And, yes, all lists are semi-colon separated, and terminated. I have
to note this point somewhere.
And so, what about renaming this key as 'Mimetypes=' ?

> 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

Not really agree on this. I'd prefer let the user free of his parameters.
Or do you mean adding another key ? So removing wildcards from Mimetypes ?

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

This suppose that the target application registers itself on DBus.
I'm not against adding such a key.
But IMHO the user usually wants run an application when he
right-clicks on an item, reusing it if it already runs, but
launching it if it doesn't ?

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

Dynamic actions are missing, you're right.
I wasn't conscious of this sort of use. Very interesting indeed.
I have to work more on the implications of having multiple actions
on a single desktop file, especially from the UI management point
of view..

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

I'll take a glance at it.

> -- 
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. Konqueror
> (http://www.konqueror.org).
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg

I should be able to update the web page this week, not sure what day
exactly. I'll come back with news soon.
Thanks a lot for your comments.

Regards
Pierre