Post by Ryan LortiePost by David FaureAdding 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.
Post by Ryan LortieWhen 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.
Post by Ryan LortieThis 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.
MimeTypes=text/plain
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.
Post by Ryan LortieIn 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" ?
Post by Ryan Lortie[...]
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)...
Post by Ryan LortieCertainly, 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...
Post by Ryan LortieNote: this discussion is _only_ about added/removed.
Yes.
Post by Ryan LortieWe 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).
Post by Ryan LortieEffectively, 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.
Post by Ryan LortieThis 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]
Post by Ryan LortiePost by David FaurePost by Ryan LortieIn 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 :-)
Post by Ryan LortiePost by David FaurePost by Ryan LortieI 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.
Post by Ryan LortieI 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"),
Post by Ryan LortieThis 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.
Post by Ryan LortiePost by David FaureI 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, ***@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5