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

[Jehan Pagès]

Hi!

A quick message!

On Sat, May 8, 2021 at 8:00 PM 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.
>

I guess it's where we diverge. I don't really want the software developers
to make a choice for people. Just helping/hinting with that choice. Now how
that choice is exactly made later on? Querying people all the first times
(as someone proposed in the original thread)? Have desktop devs and
distribution packagers make priority lists (this is already the case,
though it can't be exhaustive by definition)? Using randomness (as long as
it's consistent, so once randomness was applied once, the same software
should be called the next times) but only within an appropriate set of
software (i.e. don't put GIMP in the random list for JPEG, don't put an
image viewer for XCF…)? Something else? I don't know.

I just think that usage hinting can help for all these use cases.


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

Actually PSD is a good example because none of the Free Software have an
awesome support AFAIK. Some have better support than others on some
specific features of PSD, the other have better support on other feature
set. It's not like we can really keep track of every update every other
software does (it's not a competition anyway). I would have no idea how to
compare to others. And seriously I would feel bad to make a judgement
(based on not much) to decide that we have worse or better support than
another software.
Now multiply having to do this for the ~36 mime types GIMP seems to handle
(after a quick check in our build).

Not even counting that if we write a lower number, then our users will
complain that GIMP does not get opened when opening PSD; if I write a
bigger number, then we might get attacks by fans of other software saying
we are badmouthing through this number and that we are lying… It's
stressful and we are quite subject to attacks whatever we do, so if we now
add a note-like system, I can't imagine how it could get like. That's why
for me, it's a very very bad idea. If it gets there, I would prefer not to
use such a system. I don't want to note our own support comparatively to
others. I just want to say "yeah we handle this", then people can try and
make their own judgement.


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

Well if Qimp is good and really use the same XCF as GIMP (I'm adding this
precision because I am told there used to be a software which used XCF but
the formats slowly drifted apart, which would have been a bad situation:
not actually the same format, but recognized as the same), I wouldn't mind
it to be considered a serious contender for usage of the format. 🙂

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

It's not about not being my problem. It's about the fact I don't think we
should be choosing. For desktop devs trying to make some kind of consistent
experience (GNOME, KDE, XFCE…), I can understand that they would want to
make lists of top software for various usage, that's only fair. Similarly
on a higher level, distributions add their own touch. But should software
developers be a part of the whole choice, other than saying "here is what
my software is for"?

So really, I don't mind if there are imperfect defaults, even some
randomness to be fair, but it has to make a minimum bit of sense. Like
don't open text files in LibreOffice by default, don't open JPEG files by
default in GIMP, don't open a PDF in GIMP either as a default… these kinds
of nonsense (yeah all these happened to me at one point or another). But
yeah, if I have both LibreOffice and Calligra installed (as I understand,
Calligra also consider ODT as a native format, this example is of course a
mistake if I am wrong), then I would not see a problem if it opened in any
of these. If I have both GIMP and Krita installed and I double-click a PSD,
I would understand if it opens any of these. And so on. If the default is
not the one I expected, I would make a setting, but that's a perfectly
acceptable "mistake" IMO ("mistake" in quote, because it's not even a
mistake to me, the OS cannot be in my head and both these software are
intended to work on PSD-like files and support PSD).

Now of course, maybe we can improve the decision strategy. Say I have both
GIMP and Krita installed, but I use GIMP all the time, if my desktop were
recording such usage, it could decide in favor of GIMP the first time I
ever open a PSD (for which both programs would be registered as being of
similar intent). Basically simple machine learning based on usage
statistics.

Do we want to go that way (basic "usage learning" inside the desktop)? I
don't know, I was only giving some ideas as I'm asked to propose something.

But even without going to such extent, I am not looking for perfect
defaults choice (neither software-guided nor human-guided), only avoiding
the absurd ones.
And my belief is that human guided defaults will never be perfect either
anyway, because just anyone has different expectations.

Now someone was also proposing to always ask people. The proposition is
interesting, and I definitely understand both the people who want this and
the people who dread the idea. I am personally fine with defaults which are
globally good most of the time, and sometimes are not what I wanted, as
long as it's an acceptable mistake (i.e. not the weird cases above, which
all of us have experienced at some point in our years of usage). With such
logics (right most of the time, wrong sometimes, then I just add custom
rules), there is definitely less disturbance in my work rather than always
being popped up to choose for every new format.

So I guess my point is: don't look for perfection because it doesn't exist;
and if we ask software developers to make the choice, it can only fail. But
we can avoid the easy pitfalls by having developers document (through
metadata) what their software is intended to work on.

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

I wanted to answer this part the most to clarify: I am not jumping at you.
Sorry that it looked that way. 🙇
I can be a bit passionate, that's all, and I always write a bit too much
(even this email, I said I'd make a short answer and here it is! Long with
too many parts answered). Anyway yes, I even actually appreciated that your
email at least came back to the original proposition because the whole
thread diverged quite a lot. 🙂


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

Yes let's wait for more input.

But seriously, if I were asked to note all our supported formats on a scale
from 0 to 20, I would rather not use this at all. Just the idea that doing
this might put us in an awkward situation of comparing our support to other
software is enough to make me not want to do this, and I am dreading in
advance people attacking us with this (yes, I have become sensitive to this
type of things while working on such a known software and I became very
careful because some people are just waiting for us to make any mistake).
Also not even taking into account the amount of time it will imply to do it
right for the few dozens file formats supported.

Jehan


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

-- 
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20210508/2e74c4d1/attachment-0001.htm>