mime aliases and inheritance vs. removed associations
cfergeau at gmail.com
Tue Feb 10 09:53:06 PST 2015
Vaguely related to that, I recently had an issue with glib 2.42 and the
way it looks up default applications when inheritance is involved.
If gedit is registered as a default for text/plain, and if text/html has
no default application, but epiphany says it can handle text/html files,
the logic in g_desktop_app_info_get_defaults_for_content_type() will
cause it to pick gedit as the favoured application for text/plain while
epiphany would imo be best when there is no exact match.
I've filed https://bugzilla.gnome.org/show_bug.cgi?id=744282 against
On Sun, Nov 09, 2014 at 02:18:04PM -0500, Ryan Lortie wrote:
> One more nag about the mimeapps spec, while we're at it.
> We didn't take any care to think about aliases and inheritance.
> Aliases are probably relatively easy: I think we should aim to only ever
> store the canonical mime type names in the file, and if we are
> processing a file with non-canonical names, we should treat it as if we
> encountered the canonical name instead. That means that if someone
> added an association at one level for 'application/acrobat' and then at
> another level removed 'application/pdf' then the result would be that
> the association is broken, regardless of what string is used to do the
> Inheritance is more difficult. What does it mean if, for example, gedit
> is listed as an editor for text/plain, but then we specifically list it
> as a [Removed] for text/html? Maybe even more interesting is what
> happens if it explicitly listed as text/html but then we remove it for
> all of text/plain? Is it only removed as a fallback, or is it removed
> completely for all purposes?
> I don't know that there are "natural" answers to these questions. In
> the case of GLib we have two loops iterating (outer) over all parent
> types, in order of most specific to most general, then (inner) over all
> desktop file directories. If we encounter a remove instruction anywhere
> on the way, we add the app to a blacklist that we keep for the duration
> of the entire operation. This means that if an app removed for
> text/html at any level it will prevent it from being used for text/html
> even if it is added again for text/plain from a higher-level directory.
> This might sound weird, but consider that removals are probably only
> really recorded at the highest-level (ie: user) directory.
> On the other hand it means that if the user removes text/plain then the
> behaviour will depend on what exactly was specified in the system
> directories. If text/html was specifically mentioned as being handled
> then it will still be handled. If, however, only text/plain was
> mentioned, then the user will have removed this association. That seems
> slightly weird as well.
> I guess it comes down to user intent in a way: what is the user really
> wanting to do when they break an association between an generic text
> editor and a file named index.html? Are they breaking an association
> between this editor and all text files, or are they only intending to do
> it for html? Maybe the solution to this problem in fact lies in
> breaking specifically the association that the application declared?
> I welcome any thoughts on this matter (and particularly if you can state
> them more cogently than I've been able to do in this mail).
> xdg mailing list
> xdg at lists.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the xdg