Have a way to dynamically change software associations at distribution level

[David Faure]

On Tuesday 04 August 2009, Didier Roche wrote:
> Hello everyone,
> 
> Right now, GNU/Linux distributions (Debian, Ubuntu, from what I see it
> seems to apply to Fedora, OpenSuse and Mandrake as well…) use a static
> defaults.list file in $XDG_DATA_DIRS/applications shipped by the
> distribution for associating a mimetype to a default application.

defaults.list is a gnome-only file, it is not part of a freedesktop standard and
not read by KDE.

> To handle application priorities, the idea is to rely on the .desktop
> files having an optional InitialPreference=<Priority> (similar key to
> what KDE is using), a default priority will be used if there is no
> such key. We can setup a 100 priority for application currently
> present in defaults.list for distros, and 50 as the default priority
> if the key is not present in the .desktop file.

In KDE the default priority is 1 and desktop files which set a priority
often use 5 or 9, but well ;)

> This is a proposal for changing
> http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec
> and http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec
> specifications to handle those use cases. The main goal is to keep
> retro-compatibility for people who don't want to change their
> defaults.list. As we don't change the current layer of user choice in
> $XDG_DATA_HOME > defaults choice in $XDG_DATA_DIRS/applications, I
> will just emphasize about defaults.list and the cache: The priority
> order would be:
> 
>     * mimeapps.list for sysadmin
>     * defaults.list for distro and compatibility (at the end,
> distribution wanted to use this dynamic association will no more ship
> it)
>     * mimeinfo.cache autobuilt

I think mimeinfo.cache is also gnome-only. Or did you mean mime.cache as
specified in the shared-mime-info spec?

> Updating mimeinfo.cache file will be made as of today, when executing
> the shared-mime-info update-desktop-database tool. It will order the
> list of desktop file in the same order than the priorities in desktop
> files.

Sounds like gnome-specific code in update-desktop-database, but I don't
mind, if it leads to convergence - i.e. the goal is to generate a compatibility
file out of the primary source of information which would be InitialPreference,
right? That sounds good to me.

> That would mean with that example:
> 
>     * application/ogg=gnome-mplayer.desktop;vlc.desktop;kde4-amarok.desktop;mplayer.desktop;rhythmbox.desktop;totem.desktop;
> 
> gnome-mplayer.desktop priority < vlc.desktop priority < kde4 amarok <
> mplayer < rhythmbox < totem

Err don't you mean > rather than < ???
If the above is mimeapps.list syntax, then the first app (here gnome-mplayer.desktop)
is the preferred app. That's the syntax we adopted for mimeapps.list (where we is
basically Alex Larsson and myself on this list, nobody wrote a formal standard out
of it, unfortunately; volunteers welcome). At least I hope this is how he understood
it too :-)

> We want also to take into account the current desktop environment. For
> instance, with this example, if you are running KDE, the distribution
> default choice (if no user choice is setup) would be totem instead of
> amarok. To avoid this issue, categories will be used to prefer the
> application matching the desktop when there are several choices (ie
> KDE category when using KDE. Consequently, amarok will be used in a
> KDE environment and totem in the GNOME one, if the user doesn't change
> his/her own preferences). That would mean that we open the "default
> candidate" .desktop file to see if we fit the current environment. If
> not, we head to the previous one of the list, open the .desktop file…
> So, the default choice rule (if the user didn't change anything and
> the distro don't ship a defaults.list for this mime type) will be: the
> last .desktop application file found in the list corresponding to my
> mime type, having a category corresponding to my current desktop
> environment. If no .desktop file corresponding to the current
> environment is found, we fallback to the last entry.

So a user who wants to use amarok in gnome, just cannot, because the code
will always skip it due to a missing category?
Unless the parsing of the "global" mimeapps.list is different
from the parsing of the user-specific mimeapps.list, which sounds ugly.
Especially if you take into account that there is more than just "global" and "local",
one could set up groups of users by adding dirs in XDG_DATA_DIRS.

Also, this would break with desktop-independent apps, like firefox; it doesn't
have KDE or Gnome in Categories, and yet some distros might want to
make it the default web browser; but they would have no way of doing that,
since as soon as another web browser appears in the list, it would take priority,
with the above algorithm.


I thought the solution for "different defaults in different desktop environments"
was the current status-quo of "we share mimeapps.list but not the mechanism
for the global defaults (InitialPreference in kde, defaults.list in gnome)". I can
see how this makes the life of distributions slightly more difficult though, since
you have to set up defaults twice with different mechanisms.

Now would be a good time for me to offer a solution, after the above constructive
criticism, I guess.... Hmm. Maybe
InitialPreference-KDE=15
InitialPreference-Gnome=2
in amarok.desktop (for instance), as an alternative to a cross-desktop
InitialPreference=15 (in firefox.desktop for instance)?
However this requires distributors to patch a lot of desktop files, I'm not sure
that's workable? In fact I'm not sure of the requirements; editing a single file
like defaults.list doesn't make it very modular, while a key in the desktop file
is very modular but requires a lot of patching...

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).