mime aliases and inheritance vs. removed associations

[Christophe Fergeau]

Hey,

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

Christophe

On Sun, Nov 09, 2014 at 02:18:04PM -0500, Ryan Lortie wrote:
> hi,
> 
> 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
> lookup.
> 
> 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).
> 
> Cheers
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20150210/8aef385d/attachment.sig>