Have a way to dynamically change software associations at distribution level

[David Faure]

On Tuesday 04 August 2009, Didier Roche wrote:
> >> 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 ?).

x has multiple values. That's the whole point of this system.
The idea is: I have apps A and B, which are both good, so they
have an InitialPreference set. If both are installed, A is preferred,
so InitialPreference(A) > InitialPreference(B), but if only one is installed
then it will be used.
That's what I meant by modular: it accomodates for the fact that apps
can be installed at any time. A single file shipped by the distro doesn't
do this (it could list all apps that are packaged by the distro at the time
of the release, but it cannot list the apps that people can install on top
of it from other ISVs -- for instance CrossOver Office, hi Francois ;) ).

> and the range will be 1 to 10?

There is no upper value currently.

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

Right.

> Is there an about anywhere in a file?

I don't understand this question.

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

I don't see a need to unify the caches. The point of a cache is performance,
not interoperability; interoperability is achieved by sharing the initial source
of the data, which is right now mimeapps.list and which could be anything else
we decide in this thread, like InitialPreference for instance.
Caches can and should be left implementation-dependent IMHO; it would 
make no sense for me to try and convince other projects to use ksycoca
(which uses a very kde-centric binary format), and it would also make no
sense for KDE to use a less optimized cache.

But I'm starting to wonder if in gnome mimeinfo.cache is really a cache, or a
primary source of information?

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

Does gio ignore mimeapps.list files in other directories listed in XDG_DATA_DIRS
then?  (e.g. /usr/share/applications/mimeapps.list)
That would be a bug IMHO...

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

And it mixes up two things, no? Adjusting categories for this purpose
would also have an effect on the vfolder menu which uses the categories
in the first place...

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

mimeapps.list allowed us to finally stop copying desktop files locally,
and I would certainly NOT want to go back to that horror.
It leads to tons of problems, including desktop files with outdated information,
and desktop files pointing to uninstalled applications. Please let us
forget you even mentionned this possibility :-)

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

That seems quite reasonable.

It requires quite some coordination (or work from the distro) though:
if epiphany ships with 5 and konqueror ships with 6, then konqueror would
always be preferred and gnome users won't like it; either upstream
gnome and kde need to agree on a standard initial preference, or
all distros need to adjust those by hand to achieve desired behavior.

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

Yes but only if some applications make more sense as default in that
desktop environment than in another. To take a neutral example, fvwm
wouldn't really care so there wouldn't be a InitialPreference-fvwm key ;)

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

If the distro wants FF by default everywhere, it would just have a single key
InitialPreference=15 for FF (and less in other browsers).

On the other hand, if the distro wants konq in kde and firefox in gnome, it would write
in konqueror.desktop:
InitialPreference-KDE=20
InitialPreference-Gnome=5

This is more flexible than the use of categories alone, but indeed with your idea
of using categories only for InitialPreference equality, the distro can make an
app "preferred everywhere" and "preferred in this desktop only".
You just can't make k3b "preferred in gnome only", but I guess that wouldn't make much sense.

> My modified proposition
> (see a little above) has this drawback too, but does not propose
> multi-InitialPreference* tag.

Right. I guess I'm withdrawing my InitialPreference-* idea then, since it requires
changes to the desktop entry standard, so if we can do without, all the better.

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

OK. Maybe you guys (=all distros) can develop a .desktop-file-patching tool so the files
can be modified at install time rather than keeping actual diffs (which break
when a nearby translation is updated) in the packages... So you would put in
the package description a call like
  modify-desktop-file konqueror.desktop InitialPreference=15
Just an idea ;)

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