Have a way to dynamically change software associations at distribution level

[Didier Roche]

On Wed, Aug 19, 2009 at 11:15 AM, Alexander Larsson<alexl at redhat.com> wrote:
> 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).

This is a good summary. I absolutely agrees with this.
>
> 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.

This is a good idea so that every libs can share the same algorithm
and don't have the "libs has to do the right thing for themselve"

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

So, taking Ubuntu as an example where FF is the default for Ubuntu and
Kubuntu (IIRC, not really sure for Kubuntu). We will patch the FF
.desktop file to add DesignedFor=GNOME;KDE; entry?

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

I think you fixed our previous concern about "look at each deskop
environment specific application first" with the "DesignedFor" entry.
However, we have to define it preciselyl to not mix up this entry with
the Category one.

I reckon that we still needs to standardize some kind of priority
concept, even if the need for coordination is withdrawn with your
proposal: for instance, telling than no .desktop file must have a prio
number > 50. That will enable distros to be sure they can patch an
.desktop file to have it by default, whenever applications is
installed in the distros. With that, they don't have to look at all
application prio associated with a particular MIMEType to ensure that
one will not override their wish.

Does this seem reasonable?