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

[David Faure]

On samedi 8 mai 2021 14:53:39 CEST Jehan Pagès wrote:
> On Sat, May 8, 2021 at 11:18 AM David Faure <faure at kde.org> wrote:
> > 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.
> 
> Of course. But why is it a problem? Computers don't read in people's minds
> (and I sure hope they never will! 😆). So yes, if you installed 2 software
> which support .odt as native format (a good example because there are
> actually several software with ODT as native format), I sure don't want my
> computer to assume a *better* for me. This is the limit of what my computer
> is able to do for me.

It's not "the computer" which would assume, it's people with an actual 
biological brain would would have done that for you, to avoid bad surprises.
That's exactly the topic of this conversation: humans making choices rather 
than "the computer" randomly selecting one of the installed apps.

> Basically such numbers make no sense because we cannot exactly map a
> support level to such degree of accuracy. It will just be random numbers in
> the end.

Numbers which are used to define a priority order. What matters is the order, 
not the absolute numbers per se.

> Also such number system really implies quantifying the format support, this
> is not what my initial proposal is about. It is about the "intent". For
> instance, PSD is definitely the kind of format which is intended to be
> edited in a software as GIMP. E.g. maybe some image viewer software are
> able to display PSD, but the chances that someone with a PSD file wants to
> open it in a viewer rather than an image editor is low. So if you have
> Photoshop itself, it's ideal (native format). If you don't, GIMP or alike
> may be your best bet. But this is the "intent". We are not talking about
> level of support (which is a very complicated topic we should not go into).
> And these should not be mixed, which IMO your point system would end up
> looking like.

You're adding meaning where there isn't. I never talked about quantifying 
format support. We are both talking about defining a preference order that is 
most likely to make sense for the user. Your assumption however is that 3 
levels are enough for this.

> Basically for a desktop, yes numbers can represent preferences, not
> necessary level of support. But for the proposal I had, numbers
> representing preferences don't make sense. I mean, as software developers,
> then I would just put our software as main preferences because that's
> obviously how we use it ourselves. So using your description above ("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 […], then it
> should be below 10"), I would put native formats as 20, all "same intent"
> formats (PSD, ORA…) as 19, then all other formats as 9. That's my actual
> preference and in the end, we are back to a 3-level system. That's why a
> number system makes sense for desktop preference, not for software exposing
> its format usage.

I was merely showing how you could use the number system to model the fact 
that you determined that for GIMP, 3 levels are enough. But I'm trying to come 
up with something that is flexible enough for all cases, not just for GIMP's 
use case.

Imagine GIMP had very basic support for another editing format like PSD,
but there was another Linux application with much more complete support for 
that format... then 19 would be incorrect and a lower number would be more 
appropriate.

Imagine I start writing today an XCF editor written in Qt, a gimp competitor.
XCF would be the native mimetype for that application. But surely it shouldn't 
have the same priority as gimp, on a system with no user preference set.
As the developer of, ahem, Qimp :), I would use a much lower preference number 
than gimp, to make sure I don't get tons of bug reports from gimp users who 
suddenly end up opening xcf files in my very limited application.
In 10 years when qimp is complete, then the apps can compete on equal footing 
in the preference system, but not until then.

> > 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).
> 
> I don't mind using another word, but I really think this is a good word
> here (but maybe other wording is acceptable too). It's not a preference
> concept, that is for sure, because it makes no sense to ask software
> developers to input "preferences" as I demonstrated above. I mean, any
> software dev will prefer one's app once it is mature enough (or I sure hope
> so! Otherwise it's sad).

See above: reasonable devs wouldn't use a high number if the app is 
experimental / suboptimal / still in initial development. And if they do, I am 
counting on distros / users to push against that (or even patch it at the 
distro level). The same would happen with your proposal if people used 
"Intent" or "Native" incorrectly.

> It's really about saying what your software is intended to open: ours is
> intended to open image work-in-progress formats (our native one being XCF,
> but we have some support for other similar-intent formats, like the one
> from Photoshop, PSD, or ORA) and of course we can also open finale image
> formats (PNG, JPEG, etc.) though such formats are not specifically intended
> for editing.

Yes, those are the 3 categories of mimetypes supported by GIMP, I get that.
In GIMP the distinction is clear, I can see why you think it's all that is 
needed :)

But in my 20 years of handling this topic in KDE, I have seen many other 
subtleties that require tweaking among these 3 categories.

One more example: gvim developers are surely very proud of gvim, but do they 
really expect it to be the default text editor on a brand new Linux system? I 
surely hope not. My family members using Linux would be extremely confused if 
editing text files opened up gvim. And yet, text/plain is a native mimetype 
for all text editors, so it would (still) be on equal footing with more 
intuitive text editors like gedit or kwrite/kate, with the risk of being 
selected as default. Surely gvim should have a lower preference than those by 
default.

>  [...]
> In any case, even if you regularly edit JPEG, I am guessing that most
> people, when they double-click a JPEG file in their file browser, they want
> an image viewer to open, not an image editor (they still want their image
> editor to be accessible on right click menu).
> Oppositely if you double-click an XCF, you probably want an image editor to
> open, not a viewer (even though some viewers may have XCF preview support).
> 
> This is why it is really about intent.

That's more about the intended usage of a file format, than about the intended 
application to use for it. A text/plain file is intended to be edited by a 
text editor. Great. That doesn't tell me which one.

> > It's all a matter of ordering / priority, IMHO, not intent.
> 
> Absolutely not IMO (as explained above). Ordering and priority is left to
> the desktop or to the user. How can software developers decide of
> ordering/priority of their own applications? All we can do is tell what our
> software is for. Not tell what to prefer it to! 🤪

I get that everybody says "I shouldn't have to define ordering/priority",
in this thread I heard people say that it's not the distro's job, now you say 
it's not the software developer's job, so what's left? Anything is better than 
random... (and yes, alphabetical order is similar to random since it's based 
on a fact that is completely unrelated to what's best for the user).

> Wait what? Why should popularity even be taken into account? It's like
> saying that the big deserve to stay the big ones and we should never even
> give the chance to newcomers. I'm saying this as a GIMP developer. What you
> propose would be in our software favor, but this is absolutely not why I
> proposed this. We don't want special treatment, but the best system which
> makes the best experience for people. Some people prefer less known
> software and it's perfectly fine (to everyone's their preference!). 

Those people can make their choice. As you said yourself we're only discussing 
defaults which work for the majority, it's still all configurable by user who 
have other preferences (and distros who target specific user groups, 
possibly).

> I don't
> want GIMP to be considered a better default just because it's more popular.
> And I don't want LibreOffice to be considered obviously better just because
> it's popular.

They are popular because they do the job for most people. Why shouldn't they
be used by default, compared to other apps which less people prefer, surely 
for a good reason? (whatever the reason is: features, look, performance, ...).

> As for the "feature complete" part, I talked about this earlier, this is a
> very slippery slope. Not being feature complete is not a good enough point.
> Many people prefer the less known software (Calligra, AbiWord…). I meet
> some of these people regularly. They don't care about feature completeness

Good. I'm one of them, when it comes to presentation software, actually.
But again, we (those people) can very easily make our choice known to the 
system. Meanwhile doesn't it make sense that the default matches the 
preference of the majority of users?

What's your actual proposal for choosing among all apps that natively support 
the mimetype, other than saying "not my problem"?
If you don't define it, then it'll be the current solution which is either 
"random" or "first one alphabetically". Does it really make sense for abiword 
to be the default word processor on all linux distributions, just because it 
starts with an 'a'?

> No if you include concepts of "priority" or "preferences", this is not
> about being reasonable anymore. I would be perfectly reasonable to set high
> priority to GIMP because that's what I use daily, I work with it, that's
> what I actually want to open or show higher in right-click menus. This
> would be reasonable. I mean, you asked me my preferences! 🙄 Seriously,
> that's my true personal preferences!

Surely you are able to distinguish your preferences as a user from what the 
default preference should be for the majority of users.

> Also go to Calligra developers and tell them that they are less popular
> than LibreOffice, so it's perfectly reasonable for them to put themselves
> in low priority. Let's see what they say.

I am a Calligra developer. Well, used to be, but I know very well the other 
developers, and I have zero doubts that they would agree that Calligra in its 
current state should not be the default for new users who have LibreOffice 
installed. It would be extremely foolish to pretend otherwise, and they know 
that.

> By the way, did you know that OpenOffice is still more popular than
> LibreOffice (maybe not in Linux, but all-platform alike, in sheer number;
> at least that's what I was told). So go tell LibreOffice too that they
> would be reasonable to put themselves down a bit.

Obviously all this is only about "free desktops", not about platforms who 
don't even care about desktop files. Please stop jumping at me for using the 
word "popular" as *one* of the criteria, as if I used it as the *only* 
criteria.

And the majority of Linux distributions ships LibreOffice, not OpenOffice, 
right? So this would be moot anyway, the numbers only make a difference if 
both are installed.

> Really nothing is reasonable here. Don't ask developers to prioritize
> themselves and relatively to other. Just ask them to tell "what's my
> software main intent files?" **This** is reasonable.

It might be, but it doesn't solve the problem.

What's the point in adding complexity if it doesn't actually solve the 
problem?

> Then for more defaulting, let desktop put their own little priority list
> (as they already do), and finally let the user make the final choice (as
> already possible) if one installed several software of similar intents.
> **This too** is reasonable.

I have made my case, you have made yours, I think at this point we need 
external input. If other people with experience with this topic (e.g. 
developers of desktop environments or distributors dealing with this topic) 
agree with you that 3 levels are enough, I will be reasonable and I will drop 
pushing for more flexibility.

> I would have seriously no idea how to number most formats. We would end up
> not using it. That's not good. 🤷

The rules would be something like:

* 15-25 (default 20) for native mimetypes
* 5-15 (default 10) for mimetypes you want your app to be used for by default
* 5 if you don't specify anything
* 1-4 if you purposely want to make sure your app have very little chance of 
being used by default for this mimetype (like LibreOffice for text/plain).

So, on day one, you'd only use 20, 10, 5 as per my earlier example.
But as time goes, tweaks would be possible, depending on what other 
applications exist for those mimetypes and what makes most sense for the 
default ordering.


The alternative is to define this (the ordering of apps for a mimetype) 
outside the app desktop file, more globally, that's exactly what I thought 
distros would do in their mimeapps.lst global file, but in this thread some of 
them are clearly saying "nope, it's not our job". So all I see is people 
refusing responsibility on this topic....

The one thing that helps a little bit in all this is that not everything is 
installed by default, so the "conflict" between apps only exists between apps 
that were pre-installed, or with apps that were manually installed on top for 
one purpose and end up taking over unwanted mimetypes (like your GIMP example 
I suppose). So there's no need for anyone to decide if abiword is better than 
calligra because most users don't install both, I suppose. This is probably 
why distros don't see how to write out a full mimeapps.lst. But they could 
still ensure GIMP isn't the preferred app for PNGs, by listing all image 
viewers before gimp :). You and me are suggesting that the image viewers 
themselves are able to say in their desktop file that they should be preferred 
over GIMP. We "only" disagree on the granularity of that information, but the 
overall idea is similar. Now that we both presented our version of this idea, 
I think we need input from other people, as stated above :)

Thanks,

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