Actions extensions in File Manager

[David Faure]

On Tuesday 02 March 2010, Pierre Wieser wrote:
> ----- "David Faure" <faure at kde.org> a écrit :
> > 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?
> 
> Why not, indeed ?
> We should so also have Type=ContextMenu, for consistency.

ContextSubMenu maybe? The main context menu (the one with copy/paste/etc.) 
isn't defined by a desktop or directory file, but by the code ;). Well, doesn't 
matter much. ContextActionMenu is another possibility.

> > 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 ;)
> 
> I call it "Desktop action extension". Not very good...
> If we want keep the 'Context' idea, we could call it, e.g.,
> "File Manager Context Extension" as it actually targets more the
> file manager than the desktop itself.

It gets better: it targets more than file managers. I see more and more code 
using these action menus: the file dialog, image editors, desktop panel, etc.
Maybe "File Action Menus"?  (ok the acronym for that is already taken, but 
still). or just the "File Action Spec".

> > > 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.
> 
> I'm afraid key has already been renamed MimeTypes, somewhere
> between v0.2 and 0.3 from draft.
> It would appear wrong to me to have a singular name for a key
> which accept multiple values (and even and though DES has made
> this mistake).

Hmmpf. That's going to lead to a hell of a lot of confusion, when people then 
starting writing MimeTypes in application desktop files, or MimeType in file 
action desktop files...
I agree that it's a naming bug, but consistency has a value too...
Dunno what to decide here. I guess sharing the parsing code was a pipe dream 
anyway, so I withdraw the strong objection I almost emitted, and I'll go with 
this, but I still think this is asking for trouble.

> > > 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.
> 
> I'm relunctant to define a new key only for performance reasons,
> and not for semantic ones.
>
> From performance point of view, we have already potential problems
> with keys which accept a shell command, dynamic labels, etc.
> I think it is up to the action creator to take care of not over-using
> the flexibility of the spec.
> 
> From semantic point of view, we have other keys which accept wildcards
> (Basenames, Capabilities). We will not define special keys just to
> not have to interpret a wildcard, do we ?
> 
> I'd rather propose to specify that a) wildcard are not regexp, and
> b) wildcard character '*' is only interpreted when being a whole part
>  of the value:
> e.g. for mime types, the wildcard character must only be a toplevel
> media type, and/or a subtype. We don't want accept e.g. "ima*/*"!
> For basenames, it would only be the part before the dot, and/or the
> part after. This way, I fell the implementation will be more easy
> and less costly ?

Yes, ok, that solves my problem too.
Well, I would even say that for mimetypes the wildcard character is only 
allowed for the subtype.
*/xml makes little sense (we have aliases for this special case anyway), only 
image/* makes sense.

> Last, from an action creator point of view, mimetypes like "*/*xml*"
> or "*/*+xml" would not be useless.... So neither MimeTypeGroups
> nor my above proposition actually solve the point :(

I disagree. These two are useless, because you can express "all xml-derived 
mimetypes" by writing MimeType=application/xml
Maybe this should be written explicitely, that mimetype inheritance is 
followed, just like when looking up application desktop files for a given 
mimetype. Well, it's specified in the mimetype spec already, in a way.

> > Ah, this is what the [...] in Profiles is about?
> 
> I feel I have to write some examples ;-)

Yes :-)

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