Have a way to dynamically change software associations at distribution level

[Didier Roche]

On Wed, Aug 5, 2009 at 10:17 PM, David Faure<faure at kde.org> wrote:
> On Wednesday 05 August 2009, Didier Roche wrote:
>> > 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.
>
> Well, that's a simplification. It works when each project provides *one* application
> for a given job (mimetype).
> But we already use multiple values of InitialPreference inside kde, for instance.
> Let me find examples, then...
> dolphin(10) > konqueror-as-file-manager(9)
> kwrite(8) > kword(3) > kate(no key, so 1)   (and openoffice-writer has 5 it seems),
>  as the default ordering for text/plain files. Remember that the "preferred app" is
> not the whole story, we also need to order the apps in the RMB / "Open With..." submenu
> (and of course to handle the case where an app is uninstalled, same thing).
>

Yes, that was the next step I was planning to discuss about (but the
first implementation can be a first step until we find something
better).
In GNOME, IIRC, the order of applications showed in "Open with…" is
just ordered alphabetically.

>
> Oh, this reminds me.
> Of course the limitation of the InitialPreference approach is that it applies
> to all the mimetypes that the app is associated with; this can create trouble
> in some cases where a per-mimetype initial-preference would be needed.

I absolutely agree.

> That is, if app A handles mimetype M1 better than app B, but app B handles
> mimetype M2 better than A, and yet they both support M1 and M2 in theory
> (but for instance as "import only, no export", or "importing with losses").
> To fix that there are two solutions: splitting out into two .desktop files
> (we do that for konqueror's two "roles", for instance, but most of the time
> this is an ugly solution because you want only one instance of the app in
> the menu so you need to hide the other desktop file, and then if the user
> makes some changes to the visible desktop file it wouldn't affect the other
> half... well, corner case, maybe...).

Indeed, this seems to be suboptimal as when an user wants to edit a
menu, he/her can be confused by those multiple instances, one visible,
the other marked as hidden.

> The other solution is to invent a way to specify per-mimetype initial-preference
> in desktop files. We have a hack with an ugly syntax for this in KDE's .desktop
> file parser, but I certainly don't want to see it standardized.
> (For the curious, it's MimeType=text/plain;5;application/msword;9;
> Yes, ugly and non-standard, but we just blame the one who had the idea ;) ).

And this one is? :)
More seriously, if we replace text/plain;5 by text/plain,5 it makes a
little more sense (two kinds of separator). But it seems not to be the
right way either.

>
> Well, maybe we just forget about this and split out .desktop files in the rare
> case where this is necessary. We already split out .desktop files when the
> app support for a mimetype depends on a plugin anyway (example: okularApplication_djvu.desktop)
>

We can say, this is the first step which is well better for having
something standardized and using current environment even if it's not
the best one we can find.
Then, maybe, we can moving on in the future for something handling
mime type specific priorities.

We don't have to forget that users/admins can overwrite those defaults
when the defaults doesn't fit their needs.

>> > Does gio ignore mimeapps.list files in other directories listed in XDG_DATA_HOME
>> > then?  (e.g. /usr/share/applications/mimeapps.list)
>
> Actually, thinking about it again, I'm almost sure Alex Larsson and I discussed that
> aspect, so it doubt it ignores those files.
>
>> I will have to test it and take a look in the code. mimeapps.list is
>> not a cache file but a static one that administrators and users can
>> edit to overwrite defaults, am I [right] with that definition? (I
>> understood it in this way in the spec)
>
> Yes.
>
>> > It requires quite some coordination (or work from the distro) though:
>> > if epiphany ships with 5 and konqueror ships with 6, then konqueror would
>> > always be preferred and gnome users won't like it; either upstream
>> > gnome and kde need to agree on a standard initial preference, or
>> > all distros need to adjust those by hand to achieve desired behavior.
>>
>> Of course, this solution has the drawback to require coordination.
>> That's why we have to choose a default value from value (5 seems quite
>> reasonable) to push as a Priority fot the InitialPreference entry.
>
> In the simple case, yes, we could say "the preferred app for a given
> desktop environment can get the value X" (actually I would say 10
> rather than 5, see the list above of text/plain handlers, you can end up
> with quite a few lower-priority apps, and yet you want to order them
> correctly, so better have room under the preferred app).

I think nobody will claim against taking 10 :)

>
>> So, to sum up the current proposition status, for a given mime-type:
>> - we look first if user has overwritten it, that is to say, an entry
>> for this mime type exists in mimeapps.list in XDG_DATA_HOME
>> - then, we look for mimeapps.list in other paths of XDG_DATA_DIRS.
>> This take into account the case where administrators wants to change
>> the defaults.
>> - finally, choose the application associated with this mime-type
>> having the higher InitialPreference entry in the .desktop file
>>   -> if there are more than one candidate with the maximal
>> InitialPreference value, each library binding choose the default
>> environment using the Category entry (KDE, QT, GNOME, GTK, XFCE ...)
>> in their prefered way...
>
> Yes, assuming the gio people agree, of course; I didn't see them involved
> in this thread yet, but I don't want to "standardize" something without their okay ;)
> Alex Larsson told me at GCDS that he was quite busy this summer, you might
> have to ping him directly to get this moving forward.

In fact, we discussed during last UDS with Alex Larsson by IRC, so
he's aware of those wishes and wouldn't be surprised :)
I hadn't the time to tackle this item before and I preferred to speak
with you, fdo's guys to make something upstreamable and that can
benefit everyone :-)
As the spec changed slightly, I will ping him directly so that he can
give some feedbacks there.

>>  I'm ready to give the needed help to reach that.
>
> Oh, if you have time for this, maybe you could write the actual spec for mimeapps.list
> itself while being at it... better for the long run than "read the discussion between Alex
> and David on the list" ;-)

Does something (even just a start) has already been written for
mimeapps.list or do I have to just rely on the thread link I posted
yesterday? If there is no template, I'll get some inspiration on the
other similar specs.

> It certainly belongs to the same spec as the stuff we're discussing now; it's all part of
> the mime-apps association and priority issue.

Agreed.

Didier