mime apps specification

[David Faure]

On Tuesday 08 April 2014 13:36:28 Ryan Lortie wrote:
> On Tue, Apr 8, 2014, at 3:55, David Faure wrote:
> > Adding and removing mimetypes (at all levels) is "patching the complete
> > view of .desktop files for the current user".
> 
> I have come to think of this as a mistaken idea.  There are just too
> many steps in the process if we handle it this way.
> 
> Let's say we have the desktop cache available at each level which has
> desktop files (which is the ideal case for considering the performance
> characteristics).

Yes. But don't forget that there are mimeapps.list at other levels 
(XDG_CONFIG_*), where there are no desktop files at all.

And therefore no cache there, but the point is that the algorithms in our libs 
have to take this into account as well. For instance we can't say that a 
mimeapps.list can only refer to .desktop files of that current level and 
below, since at the /etc level that would mean: none.

> When constructing the desktop cache, I want to be able to make a simple
> list of which mime associations are added and removed by this directory.
>  I specifically don't want to have to keep a separate list of "mime
> types added via desktop files here" vs. "mime types added via
> mimeapps.list".

I think we have no other choice, given the above. We need code that handles 
mime types added by mimeapps.list, for the handling of mimeapps.list in config 
dirs, anyway. So once we have that, we might as well use the same code for the 
data dirs - either directly opening the file, or grabbing the file from the 
cache if it makes things faster. At this point I'm not even sure it makes 
things faster/simpler, so I'd be ok with just using the mimeapps files 
directly.

Which would mean, in turn, that the cache is really about the .desktop files 
only.

> This allows a very simple algorithm: I go through the directories once
> and collect the added types (applying the blacklist at each step).  I
> don't then have to make a second pass through all the directories
> checking the mime information from the desktop files.  This is
> particularly problematic when considering 'removed' associations added
> at an intermediate level.
> 
> For example, this (perhaps slightly ridiculous case):
> 
> /usr/share/applications/foo.desktop:
> 
>   MimeTypes=text/plain
> 
> /usr/local/share/applications/mimeapps.list:
> 
>   Removes foo.desktop from text/plain
> 
> ~/.local/share/applications/foo.desktop
> 
>   MimeTypes=text/plain

This particular example could be argued both way....
Way 1: foo.desktop in ~/.local is most local so it wins.
Way 2: our merged database from the user's point of view (aka "complete view") 
of .desktop files says "foo supports text/plain", but an administrator removed 
that at the /usr/local level for a given group of users, which applies after 
looking at the desktop files, so it should be ignored.

I think I don't really mind which outcome we pick for this particular example.

> In order to know that the mime type in foo.desktop in ~/ are to be
> ignored, I first have to go down through the list a first time to
> collect the mimeapps.list information and then come back up for a second
> go through the desktop file information.  Recall that both of these sets
> of information are in the same cache file.

Maybe that's where the "will to optimize further" comes from :)
If we don't cache mimeapps.list, what would be the problem with saying
"first parse all mimeapps.list, then query the .desktop database, which is 
composed of a (small) number of binary caches" ?

> [...]

> Even assume that these extra checks are expensive.  So maybe that means
> in terms of performance, the situation is actually a wash -- but I still
> think that the expectation would be that a mimeapps.list in
> /usr/share/applications acts as a modification to the MimeTypes= lines
> in the files that we find there.

What about mimeapps.list in /etc/xdg or in ~/.config?

You are back to trying to associate config dirs with data dirs, and this 
cannot possibly be done (one could have 2 config dirs and 3 data dirs, 
actually that's even the default setup).

So no, I don't think this is the expectation.

The most common use case will actually be a single set of .desktop files 
(/usr/share/applications) and a hierarchy of mimeapps.list to modify them.

The handling of .desktop files in ~/.local is only something we have to take 
care of in addition, but I don't think it makes a major difference whether 
this has more or less priority than lines in mimeapps.list. I.e. I'm fine 
either way, it just seems to me that treating all mimeapps.list on top of all 
.desktop files is a simpler rule than trying to mix and match in dirs that 
have both, then have different handling in config dirs (which only have 
mimeapps.list)...

> Certainly, I might be confused if I install an app that lists support
> for a particular mime type, but it's not supporting it due to something
> listed in a lower-level directory.

Yes. However I don't expect many people to trip over this. Removing 
associations at a global level is definitely nasty for this reason, someone 
doing this would need a pretty good reason...

> Note: this discussion is _only_ about added/removed.

Yes.

> We might sidestep the whole issue by saying that only the ~/.config and
> /etc versions of the files can add and remove associations (since this
> feature is of questionable usefulness in the files installed directly
> alongside the .desktop files where such changes could be made directly).

Well, there's also the use case of adding/removing mimetypes in /usr/kubuntu-
data-dir/share/applications/mimeapps.list (a directory that is part of 
XDG_DATA_DIRS), referring to lower-level /usr/share .desktop files. But OK, 
this example is a bit convoluted since this old setup is now addressed by 
/etc/xdg/mimeapps.list.

So yeah, we could say that (see 2 paragraphs below for a slight refinement of 
that).

>  Effectively, then, all mimeapps.list added/removed tweaks are above all
> desktop file MimeTypes= lines by simple geography of directory
> precedence, as well as by the spec.  That's sort of nice.

Well you could still make up a broken case with /etc/ removing text/plain from 
foo.desktop and the user installing foo.desktop into ~/.local, very similar to 
your example above. But I declared it acceptable, so the same applies here.

> This would give us trouble for compatibility with
> ~/.local/share/applications/ however, where these features are in active
> use today.  It's also a weird arbitrary restriction.

Right. So rather than forbid it, we can just discourage it.
The code stays the same and remains compatible, but at the same time
we don't need to optimize for the case of mimeapps.list in 
/usr/share/applications since that's discouraged.... which means not making 
mimeapps.list part of the binary cache, as per my initial suggestion :-)


[Section 2, handling of default applications]

> > > 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 think that the handling of defaults, on the other hand, should not pay
> any mind to desktop files installed at particular directories.  This is
> something that always makes sense to inherit from the system.  This is
> yet another reason that it makes sense to cleanly divide these concepts,
> I think.

Well IMHO neither should pay any mind to desktop files installed at particular 
directories ... which is another reason to apply that rule to both :-)

> > > 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.
> 
> I've firmed up my thinking here, as well: if we find an app that has
> been listed as the default for a given type, but after handling
> MimeTypes/Added/Removed for this mime type, we find that the app is not
> on the list, then we must fallback to the next default.

That's a more complex algorithm than I thought we wanted
("look up [Default Applications], if found, we're done"),
but ok, your example below shows that it would be nice to have indeed:

> This will nicely deal with the case of having an app listed as the
> default in a file in /usr while the user has removed the association
> entirely in their homedir, while allowing us to keep a strict separation
> between the concepts of added/removed and defaults.

OK.

> > 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...).
> 
> OK.  That's fine.  I actually think it's a little bit weird that we use
> the mimeapps.list for MRU like this anyway, so I'm not about to push
> further on this point.

Shall we then say "the meaning of the Added lines is from most preferred to 
least preferred", given that would match both of our views?

On the other hand, one could say adding is just adding, "as if the .desktop 
file mentionned that mimetype", and that means nothing else is implied by the 
ordering... I guess that's just a naming issue (of the section in the file), 
the real question is whether we need a preference order between desktop files.
The current KDE implementation does (it presents a sorted list to the user), 
but we can list the apps in preferred order under [Default Applications] 
instead... If that seems fine to you, then I can agree with "order of desktop 
files in Added section means nothing".

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