mime apps specification

[Ryan Lortie]

hi,

On Mon, Apr 7, 2014, at 9:45, Bastien Nocera wrote:
> 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.

This matches my expectations as well (at least I think it does...), but
this is not how the spec is currently written.

> 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().

static gboolean
g_desktop_app_info_can_remove_supports_type (GAppInfo *appinfo)
{
  return TRUE;
}



After a bit more thinking, it seems desirable to make the following
tweaks:

At each level that we have added and removed associations referring to a
desktop file that resides in the same directory as the mimeapps.list
file, we should treat the Added and Removed associations as being
exactly equivalent to this file having been edited and those entries
added/removed from the MimeTypes field.

We should forbid [added] or [removed] entries in the desktop-specific
*-mimeapps.list files -- only defaults should be allowed here.  This
means that I can now give a canonical list of "mime types supported by
this app" per desktop file in a given directory and not have it be
desktop-dependent.  This simplifies the cache.

When mimeapps.list exists in directories above the directories where the
desktop file exists (ie: in the homedir for a desktop file in /usr) then
we should treat added/removed here as equivalent to copying the file
from the lower directory to the current directory, with the MimeTypes=
line tweaked by any changes we found along the way.

All of the above depends _only_ on Added and Removed.

In order to simplify the above logic we should separate the handling of
defaults entirely.  Any language about 'default' implying 'added' should
be removed.

I consider it to be an open question as to what happens if Defaults
"picks" an application that is installed but not listed as supporting
the mimetype (either by not having it listed in the desktop file, or by
the user having removed the association).  I think this is actually not
a very interesting question because anyone who sets something as a
default should either make sure that it is supported (and not 'Removed'
by user config) and/or explicitly mentioned in 'Added'.  I would even be
happy to leave this implementation defined.

It would also be nice if we could see mention in the spec about "if
applications want to order the keys in added, it should do it by MRU
order, but this is optional" in order to document the only existing
implementation that cares about this order and to prevent other
implementations from thinking that it is appropriate to use the order
for something else.  Implementations that do not care about order are
free to ignore it and certainly don't need to update it.


Cheers