Have a way to dynamically change software associations at distribution level

[David Faure]

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).


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.
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...).
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 ;) ).

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)

> > 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).

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

>  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" ;-)
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.

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).