On Sun, 2014-04-06 at 19:50 -0400, Ryan Lortie wrote: > hi David, > > On Wed, Apr 2, 2014, at 11:06, David Faure wrote: > > After so many years, he's finally a proposal for a unified mechanism for > > selecting the default application for a given mimetype. > > A couple notes after my attempts to integrate this work with the desktop > file index: > > The multiple defaults thing is a bit strange and it makes the cache more > complex. It would be nice to just give the desktop file ID for each > type.
This was something that was possible using the old defaults.list: http://pkgs.fedoraproject.org/cgit/shared-mime-info.git/tree/defaults.list#n13 But this is a fallback that's implemented based on the available desktop files. Using this example. System-wide: - eog.desktop isn't available - gthumb.desktop is available - mimeapps.list says: image/bmp=eog.desktop;gthumb.desktop; User-wide: - no mimeapps.list - eog.desktop is available I would expect gthumb.desktop being the default for the user. Meaning that even if the mimeapps.list contains multiple values, it would only check for desktop files/applications availability at the same level. > What is the interaction between the mime cache and replaced desktop > files? > > Specifically, imagine this situation: we have 'x.desktop' in ~ and /usr. > In /usr it supports MimeType=text/plain, but the .desktop file in ~ has > no such mention. In /usr it is listed in mimeapps.info as the default > for text/plain. > > As written, the spec suggests that because x.desktop is mentioned as the > default for text/plain we should implicitly add it. What if it was in > Added, though? It seems that, at any given level, having an Added > association for a desktop file that already lists the mime type among > its MimeTypes= should be redundant, but here we see that we would get a > different result. I don't think we ever supported that, unless the mime-type was added at the user-level. Eg. if x.desktop has support for text/plain, it always does even at the user-level. The glib API seems to match that interpretation with g_app_info_can_remove_supports_type(). > Is this desirable? What does it mean if the user replaces a desktop > file with one in their homedir that has a more restrictive set of > supported mimetypes? Probably that means that the version that they > install does not support the wider range, and then the added association > is probably inappropriate -- doubly so if it was only there in order to > break a tie over the choice of default. > > Thoughts? Cheers _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
