mime apps specification

[Ryan Lortie]

hi,

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

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


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


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.  If I want to do it in one
go, I must keep track of which additions to the applications for a
supported mime type came from mimeapps.list and which came from
(universally lower-priority) desktop files.

The caveat of this is that at each level, I have to take care not to do
anything for mimeapps entries that refer to desktop files present at a
higher level.  This is not a substantial problem with the way my code is
already structured.

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.  This implies that a new desktop file
at the homedir level would ignore these modifications.

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.

Note: this discussion is _only_ about added/removed.

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

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.

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

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

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.

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

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

I've come to agree with this point of view.



Cheers