Have a way to dynamically change software associations at distribution level

[Didier Roche]

On Wed, Aug 5, 2009 at 11:24 PM, David Faure<faure at kde.org> wrote:
> 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.

That solution can only be reachable by distros at first glance. I
don't see solution at first glance a solution for this use case
directly brought by upstream.

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

ok. The current parser just void the result if it doesn't look like a
true mime-type. Understood
- Show quoted text -

>
>> > 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 looked at vlc.desktop and totem's one. That's why I didn't proposed
ordering the Priorities entry in the same order than MimeTypes. It's
not manageable.

Hum, a solution can be:
- use a global Priority entry
- if we have a specific value for some mime-type to set. we can use
mime;priority; format.

For instance (I took vlc as it handles a lot of mime types):
Priority=10;
MimeType=video/dv;5;video/mpeg;7;video/x-mpeg;video/msvideo;video/quicktime;video/x-anim;video/x-avi;video/x-ms-asf;video/x-ms-wmv;video/x-msvideo;video/x-nsv;video/x-flc;video/x-fli;application/ogg;application/x-ogg;application/x-matroska;audio/x-mp3;audio/x-mpeg;audio/mpeg;audio/x-wav;audio/x-mpegurl;audio/x-scpls;audio/x-m4a;audio/x-ms-asf;audio/x-ms-asx;audio/x-ms-wax;application/vnd.rn-realmedia;audio/x-real-audio;audio/x-pn-realaudio;application/x-flac;audio/x-flac;application/x-shockwave-flash;misc/ultravox;audio/vnd.rn-realaudio;audio/x-pn-aiff;audio/x-pn-au;audio/x-pn-wav;audio/x-pn-windows-acm;image/vnd.rn-realpix;video/vnd.rn-realvideo;audio/x-pn-realaudio-plugin;application/x-extension-mp4;audio/mp4;video/mp4;video/mp4v-es;x-content/video-vcd;x-content/video-svcd;x-content/video-dvd;x-content/audio-cdda;x-content/audio-player;video/x-flv;

So, vlc will be associated with a 5 priority for video/dv and 7 for
video/mpeg. All others mime type will have the Priority entry value,
that is 10 in this case (and 1 if not specified).

Does that makes the syntax a little bit easier? (ok, I'm sure you will
tell me it's already working like that in KDE ;-))

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

Ok, I will.

Didier