Actions extensions in File Manager

[David Faure]

Ah, I forgot to answer this older post.

On Sunday 13 December 2009, Pierre Wieser wrote:
> ----- "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 see a huge difference between the main desktop menu (where the applications 
are assigned categories and organized according to the vfolder spec) and the 
context menu (where only a few apps are listed, and no such hierarchical 
structure is expanded).

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

This key is useful so that tools like desktop-file-validate can have different 
rules depending on the type of .desktop file it's validating.
A new value for Type sounds good to me. Type=Action is maybe too generic
(the "associating mimetypes to apps" was also called "action spec" at some 
point); maybe Type=ContextAction?

In fact we're still missing a good name for this new spec, no? How do you call 
it exactly? The spec 'wiki/blog' has no title ;)

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

Sure, that's not the problem ;)

> I find your two points great. Do you have some sort of algorythm to
> find properties of a given protocol ?

We have .protocolinfo files that describe every protocol.

No idea if GIO has something like that, but I assume it does? If not in files, 
then in code...
Otherwise, we'll keep a kde extension for this, I guess.

About your question in the spec "Does a "Protocols" key would be better 
understood than a "Schemes" key ?"  : well, historically we said protocol in 
kde, but it seems the rest of world (including Qt nowadays) says "scheme", we 
I'm happy to call it "scheme".

> > * 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=' ?

I would prefer to keep the same name as in DES, this makes it easier to have 
centralized parsing code.

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

Yes. Otherwise people start writing */xml and then wonder why this doesn't 
work. Wildcards are "too" flexible - making the code non-efficient for unused 
corner cases. I would find it much more efficient to have MimeType without 
wildcard (just like in DES) and MimeTypeGroup as a separate key.

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

Not for things like "add to playlist".

If you don't have conditions on the running media player, you end up with 10 
"add to <app> playlist" for all installed apps. And often, the action doesn't 
work at all if the app is running, so the "if running" solves both issues.

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

Ah, this is what the [...] in Profiles is about?

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