MimeType key is used to indicate the MIME
Types that an application knows how to handle. Applications that
can handle multiple MIME Types would list all of the ones it can
handle in a ';' separated list, as normal. It is expected that
for some applications this list could become long. An application
is expected to be able to reasonably open files of these types
using the command listed in the
There should be no priority for MIME Types in this field, or any
form of priority in the desktop file. Priority for applications
is handled external to the
To make parsing of all the desktop files less costly, a update-desktop-database program is provided that will generate a cache file. The concept is identical to that of the 'update-mime-database' program in that it lets applications avoid reading in (potentially) hundreds of files. It will need to be run after every desktop file is installed. One cache file is created for every directory in $XDG_DATA_DIRS/applications/, and will create a file called $XDG_DATA_DIRS/applications/mimeinfo.cache.
The format of the cache is similar to that of the desktop file, and is just a list mapping mime-types to desktop files. Here's a quick example of what it would look like:
Each MIME Type is listed only once per cache file, and the
desktop-id is expected to exist in that particular directory.
That is to say, if the cache file is located at
bar.desktop refers to the file
There is also a preference list to determine preferred application of a given MIME Type. It defines the 'default' application to handle a given MIME Type. It has the same format as the cache list.
If a mime type is listed multiple times (either in the same
file, or in another file further down the search path), the
latter mention wins. If a listed file doesn't exist, or is
precluded through the
NotShowIn files, they should be ignored.
This means that applications will have to keep a history of the
preferred applications that they run into, so that if the top
desktop file for a given MIME Type isn't available, the second
one can be tested, etc.
It is also worth noting who this mechanism is defined for. It is primarily intended for use by distributors/sysadmins to provide a sane set of defaults for their users. Additionally, users themselves can use this mechanism to override the user defaults. We intentionally don't provide a way for application authors themselves to list themselves as the default for a given type, as we felt that that cannot work.