Have a way to dynamically change software associations at distribution level

[David Faure]

On Wednesday 05 August 2009, Didier Roche wrote:
> 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.

Well I object to postponing the issue, since we already implement this :)
In addition, multiple values are also necessary for handling uninstalled apps:

We can tell desktops to use 10 for the preferred app and less for others,
but if the preferred app isn't installed and a second-preferred app has 9,
it will lose against the other-desktop-environment's preferred app which
will be there with 10. No magic bullet there, some adjustment by the distro
will be necessary IMHO.

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

The reason for using ';' was that existing parsers (e.g. from other environments)
would parse the mimetype names correctly, and ignore the numbers. If you make
it text/plain,5 then older parsers will see that as the mimetype name and nothing
will work.

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

I like that you're pragmatic and want to get things done asap ;)
However now is still the right time for solving this kind of problems,
if we deem them worth solving, before we build more things on top of
incomplete solutions (e.g. InitialPreference) -- and standardize those
solutions, which makes it even harder to move away from, later.

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

I can tell you that when we had postscript files opened in karbon by default,
rather than kghostview, because of the global-ordering problem (karbon's
initial preference had been increased for a totally unrelated mimetype,
and that made it preferred above kghostview even for its poor postscript import),
the users and admins didn't say "no problem we'll adjust it", they said "kde is buggy" :)

In fact that's the issue with the global initialpreference key; it doesn't only
break with conflicts (the A/B/M1/M2 case of my previous email), it also
means that the ordering is global (among all mimetypes), so it's easy
to make a change that breaks things (for other mimetypes).
So maybe we want to standardize on a better solution instead :-)

... but I don't really have one.

Well, if nobody else has a better idea, maybe we can keep the text/plain;5;image/gif;8;
solution, it certainly beats the fragile solution of
MimeTypes=text/plain;image/gif;
Priorities=5;8;
(which becomes unmaintainable with 30 mimetypes; a number that is not uncommon
with image viewers and multimedia apps).

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

We only have the thread[s] AFAIK.

> If there is no template, I'll get some inspiration on the
> other similar specs.

I don't really know about templates and the process for writing a spec overall
(we have them in CVS, and in a git repo that seems still unofficial), this is
exactly why I didn't write it ;). I'd suggest using shared-mime-info-spec.xml, I guess.

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