mime apps specification

[Bastien Nocera]

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