Have a way to dynamically change software associations at distribution level

[Didier Roche]

2009/8/31 Stanislav Brabec <sbrabec at suse.cz>:
> 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."
>

The what seemed to be chosen term was UseByDefaultIn and not SuitedFor
(see http://www.didrocks.fr/temp/mime-actions-spec-0.1.html taking all
previous Alex and David's discussion).
I think that InitialPreference can't do without UseByDefaultIn
(considering Alex's last concerns), so, I think the couple
(InitialPreference, UseByDefaultIn) + adding multiple value to
different MIMEType was the right solution covering the maximal use
cases.

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.

Didier