Have a way to dynamically change software associations at distribution level

[Didier Roche]

On Wed, Aug 5, 2009 at 2:57 PM, David Faure<faure at kde.org> wrote:
> On Tuesday 04 August 2009, Didier Roche wrote:
>> >> To handle application priorities, the idea is to rely on the .desktop
>> >> files having an optional InitialPreference=<Priority> (similar key to
>> >> what KDE is using), a default priority will be used if there is no
>> >> such key. We can setup a 100 priority for application currently
>> >> present in defaults.list for distros, and 50 as the default priority
>> >> if the key is not present in the .desktop file.
>> >
>> > In KDE the default priority is 1 and desktop files which set a priority
>> > often use 5 or 9, but well ;)
>>
>> Ok, seems good to merge that :)
>> So, priority will be 1 for default priority, x for priority set in
>> desktop file where distribution wants to be it the normal default
>> application (x is to definied... 5 ?).
>
> x has multiple values. That's the whole point of this system.
> The idea is: I have apps A and B, which are both good, so they
> have an InitialPreference set. If both are installed, A is preferred,
> so InitialPreference(A) > InitialPreference(B), but if only one is installed
> then it will be used.

Yes. In reality, I was speaking about a generic number shared between
upstream and pushed as a fdo spec. For instance, if we can say that
upstream projects has to put 5 as a default number.
1 will be automatically chosen for applications not pushing a value.
Of course, that's a place where distros can help upstreams to be aware
and push this default value as patch for them.

Then, distros can patch (or use whatever way they wish) to change the
defaults for them.


> That's what I meant by modular: it accomodates for the fact that apps
> can be installed at any time. A single file shipped by the distro doesn't
> do this (it could list all apps that are packaged by the distro at the time
> of the release, but it cannot list the apps that people can install on top
> of it from other ISVs -- for instance CrossOver Office, hi Francois ;) ).

Exactly. That's the reason why we are discussing now :)
Static lists are just... bad :p

>
>> and the range will be 1 to 10?
>
> There is no upper value currently.

Ok. we can define that there is no upper value in the spec.

>
>> mimeinfo.cache seems to be also GNOME only (cf Alex Larsson's post
>> http://lists.freedesktop.org/archives/xdg/2008-January/009111.html).
>> It has the same syntax as mimeapps.list.
>> You told on this post that you have a different cache for KDE
>> (ksycoca, right?).
>
> Right.
>
>
>> Maybe it's the time to merge those behaviors? Finding a good man in
>> the middle solution. I volunteer to give some help in that direction
>> even if I know very little about the KDE's platform. :)
>
> I don't see a need to unify the caches. The point of a cache is performance,
> not interoperability; interoperability is achieved by sharing the initial source
> of the data, which is right now mimeapps.list and which could be anything else
> we decide in this thread, like InitialPreference for instance.
> Caches can and should be left implementation-dependent IMHO; it would
> make no sense for me to try and convince other projects to use ksycoca
> (which uses a very kde-centric binary format), and it would also make no
> sense for KDE to use a less optimized cache.
>
> But I'm starting to wonder if in gnome mimeinfo.cache is really a cache, or a
> primary source of information?