Have a way to dynamically change software associations at distribution level

[Alexander Larsson]

On Tue, 2009-08-04 at 09:16 +0200, Didier Roche wrote:
> What do you think about it? I only take a look at glib (more
> precisely, the gio module) and update-mime-info and the code to write
> to achieve that goal seems minimal.

I've not followed this thread, since I've been on vacation an very
busy with some other stuff, however I'd like to give some feedback. On
a technical level I don't mind using InitialPreference plus the kde
hack for per-mimetype initial preferences. However, on the higher
level I'm not sure the solutions discussed here are really a solution
to the problems we have. Lemme explain by taking a step back and discuss
on a higher level.

The current system works by each desktop having its own way of
specifying the default (if the shared user and sysadmin preferences
did not take effect). Incidentally the gnome version is static and
some people want to make it dynamic, but this is not inherently
connected with standardizing/sharing how this is done, so lets ignore
that for now.

The good thing about this is that each desktop can set up the defaults
however they please without having to agree with the other desktops
about the priorities of different apps. This is less work (no
coordination needed) and can lead to a better UI for each desktop (as
the defaults can be better ordered for a particular desktop). It
requires more work for distros as they need to set up two sets of
defaults, but this may not strictly be a bad thing as this also lets
them have per-desktop defaults.

The bad thing about this is that there is no standard. If an
application that is not part of either desktop (say firefox or
eclipse) wants to launch a file it will not know what to use as
default. In practice what will happen is that each application will
"randomly" pick which default method they use by what toolkit/library
they use to do the mime launching (its unlikely they implement the
specs on their own). This means that these apps work "wrongly" in some
desktops.

So, we want to fix this, and the obvious way to do that would be to
standardize the defaults. And adding a shared association priority
does that. However, the pure version of this is completely
unacceptable to either desktop, as that would mean the inability to
have the tools of each desktop be the default in that desktop. So, a
weaker version is proposed, where each desktop have *some* say in what
is the default, at least inside each priority. This may be acceptable,
although not ideal (for instance, if dolhphin(prio 10),
konqueror-filemanager(prio 9) and nautilus(prio 10) is installed on a
system then nautilus would be used in kde, which will clearly piss
some people off).

So, what has this gained the third party application? Well, its
slightly better. In the case where only apps from one desktop is
installed it now automatically will work correctly on both
desktops. However, if both desktops are installed we haven't really
gotten anywhere. We still have to make a more or less random choice of
what desktop to prefer. For instance, if it uses glib we would
implicitly favour Gnome (actually, there is an API in glib to change
this default, but you'd still have to hardcode some value in your app).

So, we made the desktop experience slightly worse, but we didn't
actually solve the problem. This is why I don't like this solution.

Of course, this is not easy to solve. Here is what I think:
* We should share at least the file format and algorithms for looking
  up the defaults. Although not necessarily the exact priorities, so
  a lookup according to the spec will have both the mimetype and the
  desktop name as arguments.
* We should standardize a way to set the default desktop to look up
  defaults in. Since such lookups may be done by all sort of apps,
  including commandline utils the only possible solution here is an
  environment variable. Each desktop would set this during launch.
  This way a third party app, or even an app from a different desktop
  would use the defaults of the running desktop.
  If this environment variable is not set we should have a sane
  fallback.
  We could use something like XDG_CURRENT_DESKTOP, and this would
  also be used for OnlyShowIn/NotShowIn.
* I don't believe in sharing the default priorities between desktop as
  some kind of global property that has to be negotiated between
  desktops, etc. The priorities are often used in-desktop to
  differentiate between two different apps in one desktop, and this
  doesn't work well if the same priority scale is used by another
  desktop too. (See the nautilus in kde example above.)

Where does this leave us? One possible solution would be to tag each
application with a set of desktops that is was "designed" for
(DesignedFor=KDE). I.e. it would be KDE in core KDE apps, unset in
"normal" apps and possibly have both KDE and GNOME in some special
distro things that want to override desktop specific core apps in both
distros.

Default lookup would be done in two steps, first it would look up only
in the apps with designed-for=$XDG_CURRENT_DESKTOP. If this fails we'd
do a second lookup in *all* desktop files. In each lookup the
InitialPreference is used as a tie-breaker, so the priorities for
e.g. core KDE apps are not affected by other desktops, but they also
work for lookups from e.g. Gnome if there are no core gnome apps for
that specific mimetype.

Implementation wise this could be done pretty simply by storing for
each mimetype implemented by a desktop file both the mimetype as-is,
plus a copy of it prefixed with each of the DesignedFor keys. So, we'd
do lookups for defaults first by looking for e.g. "KDE-text/plain" and
then "text/plain".

Opinions?