On Tuesday 02 March 2010, Pierre Wieser wrote: > ----- "David Faure" <fa...@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, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg