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

[Stefan Blachmann]

Some thoughts.

There are several "usage criteria" that could be used for ordering.
In a situation when one just wants to quickly view something then the
criteria are different ones when one wants to edit. Some people prefer
simplicity. Others prefer feature-completeness. And so on.
I doubt that  these different "usage criteria" (maybe an alternative
term for "intents"?) can be combined in one valid-for-all number.

There have been identified some usage criteria parameters:
- view ... edit  (some viewers allow simple editing too, so this is
also sort of a scale)
- degree of format support/feature completeness
- user interface (console-ish ... KDE-ish ... Gnome-ish)
- and probably more (TBD: find them)

Compared to a more-or-less arbitrary single [in]valid-for-all number,
such kind of parameters are easily definable and reasonably accurately
measurable.

If the spec allows a number of these most important characterizations,
these can be used in conjunction with the users' settings to determine
an appropriate application suitability list.

In my inner eye I now see a Gnome-ish simple configuration with a few
sliders where the user can set these preferences. So this could be
very easily configurable, too.


What I *definitely* like is the possibility of deprioritizing
particularly uncommonly used mime types/applications combos, like
text/plain+LibreOffice, or text/pdf and GIMP.


If the specification would allow association of apps to their "native"
DE, e.g. apps that belong to a particular DE, and DE-independent apps,
that would be *very* nice, too.

Because, the apps in the OpenWith list could then be sorted depending
on the users' DE preferences.
For example, DE-independent-apps > DE1 apps > DE2 apps  > DE3 apps.
This surely would make a much more orderly impression than the current
random chaos.

The possibility to show in the menu the application-associated DE
(e.g. Okular [KDE], Evince [Gnome], ...) might also be nifty.

On 5/8/21, David Faure <faure at kde.org> wrote:
> 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
>
>
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
>