Have a way to dynamically change software associations at distribution level

[Stanislav Brabec]

Didier Roche wrote:

> Then, yes, distribution can patched to their preferences (eventually
> adding UseByDefaultIn=all) and is able to deal with opening different
> application in different desktop environment (cf the spec draft). I
> want to have here Alex and David's opinion are they are more updated
> on those problematics.

Patching all desktop files in all distro to get required distro-specific
behavior seems to be a bad approach, especially if a single code base
should be used in more different products.

Example:
"openSUSE Desktop GNOME" needs Nautilus as a default file browser.
"openSUSE Mobile GNOME" need Clutter as a default file browser.
Both should be done without modifying of Nautilus or Clutter desktop
files.

It implies:

It is impossible to invent a way to select default application using
only desktop files. External configuration (however optional) must be
possible.

That is why I think:

Desktop files should provide sufficient and exact information for the
default application algorithm, but should not tell imperatives about the
default.

Good information: MimeTypes, SuitedFor, Categories, SuitedForMimeTypes,
maybe partially NotShowIn, OnlyShowIn.

Bad information: InitialPreference (desktop ignorant and imperative),
UseByDefaultIn (again an imperative).

InitialPreference don't provide information, how well is the application
integrated. It is just a number, higher number always wins. To fix this,
it must be desktop specific, and exact scale must be defined. For
example: 10 = uses the same GUI toolkit, 20 = uses the same high level
toolkit, 30 = uses the same toolkit and respect the HIG of the
environment, 40 = it is integrated with all possible features of the
environment, 50 = other applications of the environment are aware of my
application and coordinate with. Anyway, maybe it is an overkill, and
more keywords like SuitedFor would work better.

UseByDefaultIn should not exist at all. Not the upstream author, and
even not the packages should decide about it. Only desktop integrator
should do it. And desktop integrator cannot alter packages contents.

Invalid sources: NoDisplay (it affects main menu, not association)


The default application algorithm, independently on proposed
implementation, must allow modifications of the result without
modification of desktop files and without need to create any files in
the home directory.


Here is my proposal:

Mandatory things current situation:

Each desktop should provide its identification (e. g. environment
variable XDG_DESKTOP_PREFIX, XDG_FULL_DESKTOP or so).

Behavior of applications that have to decide about default application
should depend on the running desktop, not the desktop the of the
application or libraries that are used. Firefox or Nautilus should
prefer KDE applications, if they run in KDE.

The default application algorithm must be system-wide configurable
without modification of any desktop file.


And here is my idea of implementation in GNOME (work in progress):


session launch:

Set XDG_DESKTOP_PREFIX in the desktop session script (well, gnome-menus
already implement XDG_MENU_PREFIX, maybe it is possible to recycle it).


desktop-file-utils:

Improve update-desktop-database to be able to be able to decide about
default application.

The algorithm should use:
- all desktop files installed in system paths
- static configuration file, if exists
  (/etc/desktop-defaults.conf and optionally /etc/desktop-defaults.d/*.conf)

The algorithm should output:
- defaults.list for GNOME
- eventually any other cache formats


glib, gnome-vfs:

When reading defaults.list, try ${XDG_DESKTOP_PREFIX}defaults.list
first.


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