Have a way to dynamically change software associations at distribution level

Stanislav Brabec sbrabec at suse.cz
Mon Aug 31 08:24:43 PDT 2009


Didier Roche wrote: 
> 2009/8/27 Stanislav Brabec <sbrabec at suse.cz>:

> > With the SuitedFor alone, you have no chance to improve the default
> > application heuristic.
> 
> Exactly, but you still have the priorities (see the spec proposal in
> previous mail) with InitialPreference and also priorities by MimeTypes
> that make it launch the right application by default.

InitialPreference is unusable in environments with more desktops
installed or available to install, as it may force the same application
as default in all environment.

That is why I don't like adding of it to the specification - either only
one desktop environment will implement it (KDE) or we have to remove it
from all .desktop files for openSUSE or disable this feature in other
desktops. openSUSE supports more desktop environment, forcing a single
application as a default everywhere is not acceptable.

Imagine a situation that you search best application for
x-directory/normal:

Konqueror should be "best candidate" in KDE, "bad candidate" for both
GNOME and XFCE.

XFCE File browser should be "bad candidate" in KDE, "good candidate" in
GNOME and "best candidate" in XFCE.

Nautilus should be "bad candidate" in KDE, "best candidate" in GNOME and
"good candidate" in XFCE.

Such definition is impossible with InitialPreference. You may re-define
InitialPreference as a desktop specific value. Yes, then it may work a
bit better.

But there is yet another mis-conception. Initial preference should be
defined by the downstream (the distribution developers), not the
upstream of (the application developers). We have a real use cases,
where the bit-exactly the same package should be default in one GNOME
environment and not-default in another (imagine "GNOME" and "Mobile
GNOME", or a distributions with a customer overlay).

It means, that it should not be part of the desktop file (desktop file
should be an upstream stuff, identical for all desktops).

SuitedFor is a different story. "SuitedFor=GNOME;" says only: Hey, my
application is well integrated with GNOME. You should consider it.

But the algorithm for the final default must be able to accept external
configuration.

> Concerning your proposal, the drawback is that defaults.list (if I
> don't say anything wrong) is not implemented everywhere and we don't
> wait to force it. Also, there is a backward compatibility as
> defaults.list will still have a higher priority than the new
> heuristic. So, we keep distribution which don't want to migrate to a
> new behavior.

The output defaults.list looks exactly like the manually created
defaults.list used by GNOME and GLib.

Well, we have to patch glib-2.0 and gnome-vfs-2.0 anyway. Without
allowing of multiple defaults.list files, we are not able to fix
problems of following type:

Firefox should open ZIP files in file-roller in GNOME and in ARK in KDE.
Both desktops run in parallel on one machine, both home directories are
in its default (empty) state.

The heuristic is completely independent on an output format written. I
used defaults.list, because I just needed to fix just the problem with
Firefox.

To get "the second candidate" to the example in the top of the mail,
InitialPreference nor SuitedFor can provide a solution. Categories match
heuristic can provide the proper answer: "XFCE is a neighbour of GNOME,
not KDE. If an application suited for XFCE is not available, use
application suited for GNOME."

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec at suse.cz
Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                                    http://www.suse.cz/




More information about the xdg mailing list