mime apps specification

[David Faure]

On Monday 07 April 2014 10:08:51 Ryan Lortie wrote:
> 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;

So basically the distribution, or the DE, is saying "eog is better than 
gthumb".

> > User-wide:
> > - no mimeapps.list
> > - eog.desktop is available
> > 
> > I would expect gthumb.desktop being the default for the user. 

No, I would expect eog to be selected. After all, it's the better app, 
according to the distro/DE.

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

I'm pretty sure it doesn't :)
Remember, we talked about this during the summit, and we both said "parsing 
mimeapps.list is orthogonal to collecting the .desktop files available to the 
user, which happens first and provides us with a complete view of all .desktop 
files available to the user, then we refine that with mimeapps.list".

> but this is not how the spec is currently written.

The spec doesn't say anything about the way "foo.desktop" gets resolved.
It says neither "at the same level (or below)" nor "globally (= at all 
levels)".
But since this is creating ambiguity, yes, we need to decide and write it 
down.

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

If you have a x.desktop in ~/.local/share/applications/ then it masks the 
global one, it doesn't get merged with it (as discussed last week, too).

This is exactly why we need to first collect a complete view of all .desktop 
files, and then to handle mimeapps.list.

So maybe having both in the same cache is not a good solution.
When Ryan said that things like the mimetype-lookup in the cache
wouldn't handle mimeapps.list, I actually assumed the cache would only be used 
for the "complete view of the .desktop files", and that it wouldn't contain 
mimeapps.list.
If it also contains mimeapps.list, as later discussed, then we still need to 
keep in mind that it can point to .desktop files outside the current level.
(if the cache simply has .desktop files as strings, that's fine).

i.e. we shouldn't try to fully merge mimeapps.list and .desktop files in the 
cache at a given level.

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

Yes but not only "in the same directory". We moved mimeapps.list to 
XDG_CONFIG_*, there are no desktop files in these directories.

Adding and removing mimetypes (at all levels) is "patching the complete view 
of .desktop files for the current user".

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

I agree with this, there is no real use case for it.

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

Given all the possible locations for mimeapps.list (config dirs and data 
dirs), the notion of "above" isn't clear.

I would rather say: as viewed by the current user, the above is right, 
adding/removing is equivalent to a local copy of the .desktop file.

But this means in the /usr/ cache, all we can do is write down the 
added/removed mimetypes, not apply them to the .desktop files from /usr.

> 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'm ok with that.
 
> 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'.  

Yes.

> I would even be happy to leave this implementation defined.

I don't think we need to say that. If it's marked as default, it's selected as 
default, there is nothing implementation-specific there.

The only reason for our "it means Added" wording was to make it slightly 
easier to people editing the file by hand, but I agree, it makes our lives 
harder and the code slightly slower, so let's skip that.

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

I disagree. *That* is implementation specific. And e.g. the KDE4 code also 
cares about this order, and gives it another meaning (from most preferred to 
least preferred). In fact that is the wording I'd like in the spec. I think it 
would be ok with your interpretation, because you're simply making the "most 
recently used" the "preferred for next time", in the absence of a default 
being selected (right? or maybe you just ask the user in that case...).

PS: about your earlier mail: multiple defaults are a MUST have (especially in 
global dirs like /usr and /etc, since in some cases the person writing that 
file has no control over which apps will be available ("compile from sources" 
distros, etc.)).

PS2: about removing mimetypes from a .desktop file locally .... this reminds 
me of the "__noglobs__" feature of shared-mime-info. For .desktop files it's 
even implicit: any mimetype line locally replaces the global one, rather than 
adding to it. What I want to say is that using binary caches doesn't preclude 
support for local overrides that replace global data, as shown by the shared-
mime-info cache.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5