mime apps specification
hadess at hadess.net
Mon Apr 7 06:45:29 PDT 2014
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
This was something that was possible using the old defaults.list:
But this is a fallback that's implemented based on the available desktop
files. Using this example.
- eog.desktop isn't available
- gthumb.desktop is available
- mimeapps.list says:
- 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
> 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.
More information about the xdg