<div dir="ltr"><div dir="ltr">Hi!</div><div dir="ltr"><br></div><div>A quick message!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 8, 2021 at 8:00 PM David Faure <<a href="mailto:faure@kde.org">faure@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On samedi 8 mai 2021 14:53:39 CEST Jehan Pagès wrote:<br>
> On Sat, May 8, 2021 at 11:18 AM David Faure <<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>> wrote:<br>
> > But as soon as two applications are installed, which both claim level 2,<br>
> > or both claim level 1 (with no level 2 available), this proposal would<br>
> > just<br>
> > move the problem, because we again don't know which one to prefer.<br>
> <br>
> Of course. But why is it a problem? Computers don't read in people's minds<br>
> (and I sure hope they never will! 😆). So yes, if you installed 2 software<br>
> which support .odt as native format (a good example because there are<br>
> actually several software with ODT as native format), I sure don't want my<br>
> computer to assume a *better* for me. This is the limit of what my computer<br>
> is able to do for me.<br>
<br>
It's not "the computer" which would assume, it's people with an actual <br>
biological brain would would have done that for you, to avoid bad surprises.<br>
That's exactly the topic of this conversation: humans making choices rather <br>
than "the computer" randomly selecting one of the installed apps.<br></blockquote><div> </div><div>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.</div><div><br></div><div>I just think that usage hinting can help for all these use cases.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Basically such numbers make no sense because we cannot exactly map a<br>
> support level to such degree of accuracy. It will just be random numbers in<br>
> the end.<br>
<br>
Numbers which are used to define a priority order. What matters is the order, <br>
not the absolute numbers per se.<br>
<br>
> Also such number system really implies quantifying the format support, this<br>
> is not what my initial proposal is about. It is about the "intent". For<br>
> instance, PSD is definitely the kind of format which is intended to be<br>
> edited in a software as GIMP. E.g. maybe some image viewer software are<br>
> able to display PSD, but the chances that someone with a PSD file wants to<br>
> open it in a viewer rather than an image editor is low. So if you have<br>
> Photoshop itself, it's ideal (native format). If you don't, GIMP or alike<br>
> may be your best bet. But this is the "intent". We are not talking about<br>
> level of support (which is a very complicated topic we should not go into).<br>
> And these should not be mixed, which IMO your point system would end up<br>
> looking like.<br>
<br>
You're adding meaning where there isn't. I never talked about quantifying <br>
format support. We are both talking about defining a preference order that is <br>
most likely to make sense for the user. Your assumption however is that 3 <br>
levels are enough for this.<br>
<br>
> Basically for a desktop, yes numbers can represent preferences, not<br>
> necessary level of support. But for the proposal I had, numbers<br>
> representing preferences don't make sense. I mean, as software developers,<br>
> then I would just put our software as main preferences because that's<br>
> obviously how we use it ourselves. So using your description above ("if<br>
> it's not your native mimetype, then the number should be below 20", and "if<br>
> not a mimetype where it makes sense for your app to be default […], then it<br>
> should be below 10"), I would put native formats as 20, all "same intent"<br>
> formats (PSD, ORA…) as 19, then all other formats as 9. That's my actual<br>
> preference and in the end, we are back to a 3-level system. That's why a<br>
> number system makes sense for desktop preference, not for software exposing<br>
> its format usage.<br>
<br>
I was merely showing how you could use the number system to model the fact <br>
that you determined that for GIMP, 3 levels are enough. But I'm trying to come <br>
up with something that is flexible enough for all cases, not just for GIMP's <br>
use case.<br>
<br>
Imagine GIMP had very basic support for another editing format like PSD,<br>
but there was another Linux application with much more complete support for <br>
that format... then 19 would be incorrect and a lower number would be more <br>
appropriate.<br></blockquote><div> </div><div>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.</div><div>Now multiply having to do this for the ~36 mime types GIMP seems to handle (after a quick check in our build).<br></div><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Imagine I start writing today an XCF editor written in Qt, a gimp competitor.<br>
XCF would be the native mimetype for that application. But surely it shouldn't <br>
have the same priority as gimp, on a system with no user preference set.<br>
As the developer of, ahem, Qimp :), I would use a much lower preference number <br>
than gimp, to make sure I don't get tons of bug reports from gimp users who <br>
suddenly end up opening xcf files in my very limited application.<br>
In 10 years when qimp is complete, then the apps can compete on equal footing <br>
in the preference system, but not until then.<br></blockquote><div><br></div><div>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. 🙂<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > Can we please use any other word? It gets really confusing with the intent<br>
> > mechanism mentioned by the desktop entry spec (and now the intent-apps<br>
> > spec).<br>
> <br>
> I don't mind using another word, but I really think this is a good word<br>
> here (but maybe other wording is acceptable too). It's not a preference<br>
> concept, that is for sure, because it makes no sense to ask software<br>
> developers to input "preferences" as I demonstrated above. I mean, any<br>
> software dev will prefer one's app once it is mature enough (or I sure hope<br>
> so! Otherwise it's sad).<br>
<br>
See above: reasonable devs wouldn't use a high number if the app is <br>
experimental / suboptimal / still in initial development. And if they do, I am <br>
counting on distros / users to push against that (or even patch it at the <br>
distro level). The same would happen with your proposal if people used <br>
"Intent" or "Native" incorrectly.<br>
<br>
> It's really about saying what your software is intended to open: ours is<br>
> intended to open image work-in-progress formats (our native one being XCF,<br>
> but we have some support for other similar-intent formats, like the one<br>
> from Photoshop, PSD, or ORA) and of course we can also open finale image<br>
> formats (PNG, JPEG, etc.) though such formats are not specifically intended<br>
> for editing.<br>
<br>
Yes, those are the 3 categories of mimetypes supported by GIMP, I get that.<br>
In GIMP the distinction is clear, I can see why you think it's all that is <br>
needed :)<br>
<br>
But in my 20 years of handling this topic in KDE, I have seen many other <br>
subtleties that require tweaking among these 3 categories.<br>
<br>
One more example: gvim developers are surely very proud of gvim, but do they <br>
really expect it to be the default text editor on a brand new Linux system? I <br>
surely hope not. My family members using Linux would be extremely confused if <br>
editing text files opened up gvim. And yet, text/plain is a native mimetype <br>
for all text editors, so it would (still) be on equal footing with more <br>
intuitive text editors like gedit or kwrite/kate, with the risk of being <br>
selected as default. Surely gvim should have a lower preference than those by <br>
default.<br>
<br>
>  [...]<br>
> In any case, even if you regularly edit JPEG, I am guessing that most<br>
> people, when they double-click a JPEG file in their file browser, they want<br>
> an image viewer to open, not an image editor (they still want their image<br>
> editor to be accessible on right click menu).<br>
> Oppositely if you double-click an XCF, you probably want an image editor to<br>
> open, not a viewer (even though some viewers may have XCF preview support).<br>
> <br>
> This is why it is really about intent.<br>
<br>
That's more about the intended usage of a file format, than about the intended <br>
application to use for it. A text/plain file is intended to be edited by a <br>
text editor. Great. That doesn't tell me which one.<br>
<br>
> > It's all a matter of ordering / priority, IMHO, not intent.<br>
> <br>
> Absolutely not IMO (as explained above). Ordering and priority is left to<br>
> the desktop or to the user. How can software developers decide of<br>
> ordering/priority of their own applications? All we can do is tell what our<br>
> software is for. Not tell what to prefer it to! 🤪<br>
<br>
I get that everybody says "I shouldn't have to define ordering/priority",<br>
in this thread I heard people say that it's not the distro's job, now you say <br>
it's not the software developer's job, so what's left? Anything is better than <br>
random... (and yes, alphabetical order is similar to random since it's based <br>
on a fact that is completely unrelated to what's best for the user).<br>
<br>
> Wait what? Why should popularity even be taken into account? It's like<br>
> saying that the big deserve to stay the big ones and we should never even<br>
> give the chance to newcomers. I'm saying this as a GIMP developer. What you<br>
> propose would be in our software favor, but this is absolutely not why I<br>
> proposed this. We don't want special treatment, but the best system which<br>
> makes the best experience for people. Some people prefer less known<br>
> software and it's perfectly fine (to everyone's their preference!). <br>
<br>
Those people can make their choice. As you said yourself we're only discussing <br>
defaults which work for the majority, it's still all configurable by user who <br>
have other preferences (and distros who target specific user groups, <br>
possibly).<br>
<br>
> I don't<br>
> want GIMP to be considered a better default just because it's more popular.<br>
> And I don't want LibreOffice to be considered obviously better just because<br>
> it's popular.<br>
<br>
They are popular because they do the job for most people. Why shouldn't they<br>
be used by default, compared to other apps which less people prefer, surely <br>
for a good reason? (whatever the reason is: features, look, performance, ...).<br>
<br>
> As for the "feature complete" part, I talked about this earlier, this is a<br>
> very slippery slope. Not being feature complete is not a good enough point.<br>
> Many people prefer the less known software (Calligra, AbiWord…). I meet<br>
> some of these people regularly. They don't care about feature completeness<br>
<br>
Good. I'm one of them, when it comes to presentation software, actually.<br>
But again, we (those people) can very easily make our choice known to the <br>
system. Meanwhile doesn't it make sense that the default matches the <br>
preference of the majority of users?<br>
<br>
What's your actual proposal for choosing among all apps that natively support <br>
the mimetype, other than saying "not my problem"?<br></blockquote><div><br></div><div>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"?</div><div><br></div><div>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).<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div>And my belief is that human guided defaults will never be perfect either anyway, because just anyone has different expectations.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If you don't define it, then it'll be the current solution which is either <br>
"random" or "first one alphabetically". Does it really make sense for abiword <br>
to be the default word processor on all linux distributions, just because it <br>
starts with an 'a'?<br>
<br>
> No if you include concepts of "priority" or "preferences", this is not<br>
> about being reasonable anymore. I would be perfectly reasonable to set high<br>
> priority to GIMP because that's what I use daily, I work with it, that's<br>
> what I actually want to open or show higher in right-click menus. This<br>
> would be reasonable. I mean, you asked me my preferences! 🙄 Seriously,<br>
> that's my true personal preferences!<br>
<br>
Surely you are able to distinguish your preferences as a user from what the <br>
default preference should be for the majority of users.<br>
<br>
> Also go to Calligra developers and tell them that they are less popular<br>
> than LibreOffice, so it's perfectly reasonable for them to put themselves<br>
> in low priority. Let's see what they say.<br>
<br>
I am a Calligra developer. Well, used to be, but I know very well the other <br>
developers, and I have zero doubts that they would agree that Calligra in its <br>
current state should not be the default for new users who have LibreOffice <br>
installed. It would be extremely foolish to pretend otherwise, and they know <br>
that.<br>
<br>
> By the way, did you know that OpenOffice is still more popular than<br>
> LibreOffice (maybe not in Linux, but all-platform alike, in sheer number;<br>
> at least that's what I was told). So go tell LibreOffice too that they<br>
> would be reasonable to put themselves down a bit.<br>
<br>
Obviously all this is only about "free desktops", not about platforms who <br>
don't even care about desktop files. Please stop jumping at me for using the <br>
word "popular" as *one* of the criteria, as if I used it as the *only* <br>
criteria.<br></blockquote><div><br></div><div>I wanted to answer this part the most to clarify: I am not jumping at you. Sorry that it looked that way. 🙇</div><div>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. 🙂<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And the majority of Linux distributions ships LibreOffice, not OpenOffice, <br>
right? So this would be moot anyway, the numbers only make a difference if <br>
both are installed.<br>
<br>
> Really nothing is reasonable here. Don't ask developers to prioritize<br>
> themselves and relatively to other. Just ask them to tell "what's my<br>
> software main intent files?" **This** is reasonable.<br>
<br>
It might be, but it doesn't solve the problem.<br>
<br>
What's the point in adding complexity if it doesn't actually solve the <br>
problem?<br>
<br>
> Then for more defaulting, let desktop put their own little priority list<br>
> (as they already do), and finally let the user make the final choice (as<br>
> already possible) if one installed several software of similar intents.<br>
> **This too** is reasonable.<br>
<br>
I have made my case, you have made yours, I think at this point we need <br>
external input. If other people with experience with this topic (e.g. <br>
developers of desktop environments or distributors dealing with this topic) <br>
agree with you that 3 levels are enough, I will be reasonable and I will drop <br>
pushing for more flexibility.<br></blockquote><div><br></div><div>Yes let's wait for more input.</div><div><br></div><div>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.<br></div><div><br></div><div>Jehan<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I would have seriously no idea how to number most formats. We would end up<br>
> not using it. That's not good. 🤷<br>
<br>
The rules would be something like:<br>
<br>
* 15-25 (default 20) for native mimetypes<br>
* 5-15 (default 10) for mimetypes you want your app to be used for by default<br>
* 5 if you don't specify anything<br>
* 1-4 if you purposely want to make sure your app have very little chance of <br>
being used by default for this mimetype (like LibreOffice for text/plain).<br>
<br>
So, on day one, you'd only use 20, 10, 5 as per my earlier example.<br>
But as time goes, tweaks would be possible, depending on what other <br>
applications exist for those mimetypes and what makes most sense for the <br>
default ordering.<br>
<br>
<br>
The alternative is to define this (the ordering of apps for a mimetype) <br>
outside the app desktop file, more globally, that's exactly what I thought <br>
distros would do in their mimeapps.lst global file, but in this thread some of <br>
them are clearly saying "nope, it's not our job". So all I see is people <br>
refusing responsibility on this topic....<br>
<br>
The one thing that helps a little bit in all this is that not everything is <br>
installed by default, so the "conflict" between apps only exists between apps <br>
that were pre-installed, or with apps that were manually installed on top for <br>
one purpose and end up taking over unwanted mimetypes (like your GIMP example <br>
I suppose). So there's no need for anyone to decide if abiword is better than <br>
calligra because most users don't install both, I suppose. This is probably <br>
why distros don't see how to write out a full mimeapps.lst. But they could <br>
still ensure GIMP isn't the preferred app for PNGs, by listing all image <br>
viewers before gimp :). You and me are suggesting that the image viewers <br>
themselves are able to say in their desktop file that they should be preferred <br>
over GIMP. We "only" disagree on the granularity of that information, but the <br>
overall idea is similar. Now that we both presented our version of this idea, <br>
I think we need input from other people, as stated above :)<br>
<br>
Thanks,<br>
<br>
-- <br>
David Faure, <a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>, <a href="http://www.davidfaure.fr" rel="noreferrer" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE Frameworks 5<br>
<br>
<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">ZeMarmot open animation film<br><a href="http://film.zemarmot.net" target="_blank">http://film.zemarmot.net</a><br>Liberapay: <a href="https://liberapay.com/ZeMarmot/" target="_blank">https://liberapay.com/ZeMarmot/</a><br>Patreon: <a href="https://patreon.com/zemarmot" target="_blank">https://patreon.com/zemarmot</a><br>Tipeee: <a href="https://www.tipeee.com/zemarmot" target="_blank">https://www.tipeee.com/zemarmot</a></div></div>