InitialPreference (Re: New `MimeType` fields in .desktop)

[David Faure]

On lundi 3 mai 2021 15:36:05 CEST Jehan Pagès wrote:
> Now if we comes into PSD or ORA files, these are not GIMP's native files,
> but they have clearly similar intent and since we support it, yes GIMP is a
> very sane choice too (but if Photoshop were on Linux for instance, I would
> say it should advertize to be about editing PSD, hence take precedence when
> installed).

I see. Basically you're defining three levels of initial preference,
level 2 for native mimetypes, level 1 for "it makes sense to use this app for 
these mimetypes too, by default", level 0 for "supported, but should have low 
priority".

But as soon as two applications are installed, which both claim level 2,
or both claim level 1 (with no level 2 available), this proposal would just 
move the problem, because we again don't know which one to prefer.

So, why not go for an actual number, like the InitialPreference key that KDE 
has had forever? It is the same idea, but more expressive because apps can be 
ordered along a larger scale. We can still document that "if it's not your 
native mimetype, then the number should be below 20", and "if not a mimetype 
where it makes sense for your app to be default [I'm trying to explain your 
IntentMimeType key here, but probably not doing a good job at it], then it 
should be below 10".

The number should be per-mimetype though, unlike KDE's old InitialPreference 
key which is global to the desktop file (oops, that was a bad idea).

> Finally we can open various end-formats (PNG, JPEG, WebM, and a few dozens
> more…) so GIMP advertizes it in its desktop file. It's important because it
> allows GIMP to be in the proposed secondary software (commonly right-click
> menu item "open with") which makes life easier to people; and also because
> in worst case when no other software can view some image format, even if
> you don't want to edit it, at least you can view it in GIMP as a fallback

Yes.

> This is not a GIMP-only situation. I remember cases in my experience where
> LibreOffice would open .txt files (like what?!) and other similar weird
> events. Right now, we are in this situation where the default is regularly
> just weird and there have been various reports of this for years.

Yes.

This is why org.kde.kwrite.desktop has InitialPreference=8 
and writer.desktop has InitialPreference=5.

> So my proposition is not about View vs Edit, please read it.

Yes, sorry, I was only referring to old suggestions prompted by the reduced 
reasoning of "I don't want to use gimp to view a PNG file, let's distinguish 
view and edit". Let's move on.

> It is an intent concept

Can we please use any other word? It gets really confusing with the intent 
mechanism mentioned by the desktop entry spec (and now the intent-apps spec).

It also makes little sense to me. We don't know the user intent, so I think 
you meant "the app intends to be used for mimetype X", but that's true for all 
mimetypes it supports, if no other apps is available for it....
It's all a matter of ordering / priority, IMHO, not intent.

> the intent is not too accurate on purpose, because at some
> point, over-precision doesn't make sense. Yes at some point the user will
> have to choose. For instance the format `.odt` is a valid native format for
> LibreOffice, OpenOffice and Calligra AFAIK, so if you have all 3 installed,
> the default could be any of these (until an explicit user decision).

This is a good example of why numbers would help compared to only 3 levels.
Even though ODT is the native mimetype for all three, Calligra cannot claim to 
be as feature complete (and popular) as LibreOffice/OpenOffice so it would be 
reasonable for it to ship with a lower default-preference number.

I completely realize that all this relies on application developers being 
reasonable (as you said too), and that a global ordering (for a given 
mimetype) among different communities is quite hard to achieve. So it won't be 
perfect either, but as you say, it would be an improvement already, because at 
least it will provide a way to solve the issue, in the case where people 
agree.

In summary, I suggest that we combine those two ideas, by documenting ranges 
to be used for native mimetypes, for "well supported, makes sense as default" 
mimetypes (your PSD example), and for "also supported, but with low preference 
by default" mimetypes.

What I don't know, is how to actually write it out in the application desktop 
files.

Maybe with an [InitialPreference] group where we can write
image/x-xcf=20
image/x-compressed-xcf=20
image/x-psd=10
image/openraster=10

[and all other mimetypes listed in the MimeType field, would default to 5 or 
something like that]

In KDE we made InitialPreference default to 1, and I remember regretting that 
choice, it made it impossible to say "should be less than this other app whose 
desktop file we don't control and which doesn't use this feature".

What do you think?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5