Have a way to dynamically change software associations at distribution level

Tue Aug 4 05:25:56 PDT 2009

On Tue, Aug 4, 2009 at 11:02 AM, David Faure<faure at kde.org> wrote:
> 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.

Ok, thanks for the clarification.

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

Ok, seems good to merge that :)
So, priority will be 1 for default priority, x for priority set in
desktop file where distribution wants to be it the normal default
application (x is to definied... 5 ?).
and the range will be 1 to 10?

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

mimeinfo.cache seems to be also GNOME only (cf Alex Larsson's post
http://lists.freedesktop.org/archives/xdg/2008-January/009111.html).
It has the same syntax as mimeapps.list.
You told on this post that you have a different cache for KDE
(ksycoca, right?). Is there an about anywhere in a file?

Maybe it's the time to merge those behaviors? Finding a good man in
the middle solution. I volunteer to give some help in that direction
even if I know very little about the KDE's platform. :)

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

Oh right, I got puzzled by the invocation of inversing the Glist in
gio, but it's just an implementation detail :)
After performing some additional tests, yes, the current
implementation (for GNOME, at least, but you seems to confirm for KDE)
is >.

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

Hum, that's was not the intention. The parsing is made twice (in gio
at least): one for mimeapps and one for mimeinfo.cache (the "global
mimeapps.list"). I was thinking about using Category only for the
latter file. The other is platform independent and only rely on user's
choices, whatever the environment is used (we can use also QT/GTK
Category depending on the environment).
and that's right that's not a very good option if we set up group of
users by adding dirs in XDG_DATA_DIRS, I wasn't aware of this use
case.

The other possibility is to copy locally desktop files changing their
priority and using this one. If I understood it right, that was how
KDE3 was behaving, right? But again, that not seems to be very
comfortable.

> 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 was thinking that distros will bump priorities for their defaults
(and remove then defaults.list for GNOME). For instance, FF in Ubuntu
would have a priority of 9 and epiphany, which is not our default, 5
or 1. So, the logic might be:
First: user choice
Then: Priority
Finally: if max(priority) is not unique, use the Categories to look at
the best suited application.

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

Exactly, and if a distribution wants to add some others features like
this dynamic association, it makes life a little harder too :)
Again, if we can find a common solution, this will help distributions
and desktop environment too. I'm ready to give the needed help to
reach that.

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

So, you propose that every desktop environment would have its own
InitialPreference-whatever entry?
I don't really see how this can help regarding the previous example
about Firefox (both konqueror and firefox application having the same
priority, the distribution if she wants firefox by default in the KDE
environment has to patch it to bump it to 16). My modified proposition
(see a little above) has this drawback too, but does not propose
multi-InitialPreference* tag.

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

Exactly, in both propositions a lot of desktop file (at least,
default's one) have to be patched.

Didier