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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg
pgpm6cs4n3L1u.pgp
Description: PGP signature
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
