update to new mimeapps.list specification

Ryan Lortie desrt at desrt.ca
Sun Apr 13 14:53:45 PDT 2014


I've been communicating with David about updates to make some minor
tweaks and clarifications to the new mimeapps.list specification that he
drafted.  Here is what I have.

The main gist of the changes:

Added and Default are now completely separate with their separate
reasons for existing greatly clarified.

For added/removed, we now consider desktop files and mimeapps.list to be
handled at the same time.  Previously, all instructions, from even the
lowest level mimeapps.list (ie: /usr), had precedence over desktop
files, even if they were installed at the highest level (user's
homedir).  This is no longer the case.  We consider .desktop files
listing MimeType= in a directory alongside a mimeapps.list file as being
equivalent to those desktop ids appearing under [Added Associations]
(after any entries that are already there).

The fact that order is important for "most preferred" is clarified.  The
fact that the default may be different than the most preferred is also
clarified.  In GNOME, we use most preferred to mean most-recently-used,
which could very well be different than the desired default.

Default is now a very simple process: we simply go through all of the
mimeapps.list files, in order, looking for defaults.  The default app is
the first one we find a desktop file for.  We do not care if the desktop
file is available from a higher-precedence directory.

Put simply: installing a desktop file in a higher precedent directory
will cause lower-level added/removed associations impacting that
application to be ignored, but not declarations of defaults.  This makes
sense because we don't expect that associations will be added or removed
at the lower levels, but we do expect that the distro may provide a
reasonable set of defaults.

When handling added/removed, there is simplicity gained by treating
desktop files as more or less the same as mimeapps.list.  In fact, the
existing mimeinfo.cache file looks quite a lot like mimeapps.list
(except for a different group name) and we can very easily use it
directly as if it were just another mimeapps.list file.  It also allows
us to make only one pass through the directories while collecting the
list of applications that support a given type, which will be
particularly useful once we have the cache (since we only need to store
supported type information in the file in one place).


More information about the xdg mailing list