Have a way to dynamically change software associations at distribution level

[PCMan]

Here are some comments.
On Wed, Aug 19, 2009 at 5:15 PM, Alexander Larsson<alexl at redhat.com> wrote:
> 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.
But we still have a common way for other desktops or window managers
who don't have their own way to set defaults.
> 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.
If we are going to solve the "common way to set defaults" problem now,
can we solve the problem with "default web browser and terminal
emulators" at the same time? This is just as important and more or
less a similar issue with the currently discussed one.
> 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).
Good example

> 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.
Agree with this proposal. Other projects from Portland project like
xdg-utils can also benefit from this. For us, currently we use
environment variable DESKTOP_SESSION in LXDE. Having
XDG_CURRENT_DESKTOP is a good idea. But what if the users don't use
any DE? Some poeple are still using fluxbox, window maker, or
icewm...etc?
> * 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.
I would prefer using existing and backward compatible solution rather
than introduce a new key.
Categories=KDE; or GNOME; basically can solve this already.
See the desktop menu spec:
http://standards.freedesktop.org/menu-spec/latest/apa.html
We just need to add other registered desktop environments recognized
by OnlyShowIn to registered categories. All applications specifically
designed for a desktop should have Categories key properly set.
Otherwise it should be regarded as desktop-neutral.
> 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".
This would make things even more complicated. Properly setting
Categories can already solve this. Under GNOME implementation should
give applications with Categories=GNOME; higher priority, and vice
versa in KDE. This can cleanly solve the problems when two apps have
the same priority. The only concern was performance since search in a
string list is slower than direct comparison of two strings. However
the difference is minimal in real world use case.
Besides, I think desktop-utils can also create a cache named
categories.cache with content like this.
[Categories]
GNOME=nautilus.desktop;gcalctool.desktop;epiphany.desktop;....
KDE=dolphin.desktop;ark.desktop;kopete.desktop;...
WebBrowser=firefox.desktop;konqueror.desktop;opera.desktop;
Terminal=gnome-terminal.desktop;konsole.desktop;roxterm.desktop;
<CategoryName>=<list of desktop files with this category in Categories value>

With this, you can easily find all available web browsers or terminal
emulators installed on the system or can easily check if a desktop
entry file is designed for a specific desktop without opening and
parsing it. This could both solve performance problem and provide
useful informations to applications without changing any existing
spec.
> Opinions?
>
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>