Have a way to dynamically change software associations at distribution level

[Didier Roche]

2009/9/1 Stanislav Brabec <sbrabec at suse.cz>:
> 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.
>
>


Can you please explain a little bit your heuristic to produce your default list?

Aslo, XDG_DESKTOP_PREFIX is approximately the same than Alexander's
proposal of XDG_CURRENT_DESKTOP we integrated into the spec (and yes,
we can use it in defaults.list).

So, with your use case, if we take static configuration file in the
algorithm, let's say that Totem is the best one on the default
desktop, it will use it has it's on the configuration file, but if you
bye a DVD player that is not in this intial list from default
applications (based on your distribution), how can you integrate it so
that it's been associated by default?

And I don't see how you fix this issue with your proposal:
> "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.