<div dir="ltr"><div>Hi!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 8, 2021 at 11:18 AM 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 lundi 3 mai 2021 15:36:05 CEST Jehan Pagès wrote:<br>
> Now if we comes into PSD or ORA files, these are not GIMP's native files,<br>
> but they have clearly similar intent and since we support it, yes GIMP is a<br>
> very sane choice too (but if Photoshop were on Linux for instance, I would<br>
> say it should advertize to be about editing PSD, hence take precedence when<br>
> installed).<br>
<br>
I see. Basically you're defining three levels of initial preference,<br>
level 2 for native mimetypes, level 1 for "it makes sense to use this app for <br>
these mimetypes too, by default", level 0 for "supported, but should have low <br>
priority".<br>
<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 just <br>
move the problem, because we again don't know which one to prefer.<br></blockquote><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So, why not go for an actual number, like the InitialPreference key that KDE <br>
has had forever? It is the same idea, but more expressive because apps can be <br>
ordered along a larger scale. We can still document that "if it's not your <br>
native mimetype, then the number should be below 20", and "if not a mimetype <br>
where it makes sense for your app to be default [I'm trying to explain your <br>
IntentMimeType key here, but probably not doing a good job at it], then it <br>
should be below 10".<br></blockquote><div><br></div><div>The thread has been going for so long, maybe I misremember, but I think someone else proposed this. But no this is wrong for several reasons:</div><div><br></div><div>- First giving an exact level of support is often hard if not impossible to give. Like our level of support to PNG is probably pretty high. But some weird formats, we often discover new stuff (especially when no spec exist, or incomplete specs, etc. Like PSD has a spec, by Adobe, visible on the web but it's actually very incomplete so it's hard to know exactly how good an application is for this format).</div><div>- Also 2 applications may have different parts of a format supported (or rather different non-supported features). So they can somehow have a similar level of support yet with various featureset. Therefore a "number" representing support level is completely meaningless to compare these applications anyway. In the end, it can only depend on everyone's exact need (which the OS/desktop/computer cannot guess for them).</div><div>- If a dev if really confident and puts every support high, whereas a prudent one would put low number, we would just end up having the software from the confident dev open everything.</div><div><br></div><div>Edit: I realized while continuing to answer that this number is not about level of support, but more about "priority". This is bad too, maybe even worse. I'll explain this in further answers anyway that devs cannot give priority for their own application!<br></div><div><br></div><div>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.</div><div><br></div><div>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.<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>
The number should be per-mimetype though, unlike KDE's old InitialPreference <br>
key which is global to the desktop file (oops, that was a bad idea).<br></blockquote><div><br></div><div>Yes but it actually shows that such point system can have some sense on a desktop-level. Because yes KDE for instance can create its own preference system for defaults (until the user made its own preferences). For instance, first prioritize the most robust KDE applications, then some experimental ones, then Qt apps, then the rest… (I guess) Here it makes sense.<br></div><div><br></div><div>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.<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>
> Finally we can open various end-formats (PNG, JPEG, WebM, and a few dozens<br>
> more…) so GIMP advertizes it in its desktop file. It's important because it<br>
> allows GIMP to be in the proposed secondary software (commonly right-click<br>
> menu item "open with") which makes life easier to people; and also because<br>
> in worst case when no other software can view some image format, even if<br>
> you don't want to edit it, at least you can view it in GIMP as a fallback<br>
<br>
Yes.<br>
<br>
> This is not a GIMP-only situation. I remember cases in my experience where<br>
> LibreOffice would open .txt files (like what?!) and other similar weird<br>
> events. Right now, we are in this situation where the default is regularly<br>
> just weird and there have been various reports of this for years.<br>
<br>
Yes.<br>
<br>
This is why org.kde.kwrite.desktop has InitialPreference=8 <br>
and writer.desktop has InitialPreference=5.<br>
<br>
> So my proposition is not about View vs Edit, please read it.<br>
<br>
Yes, sorry, I was only referring to old suggestions prompted by the reduced <br>
reasoning of "I don't want to use gimp to view a PNG file, let's distinguish <br>
view and edit". Let's move on.<br></blockquote><div>No prob! 🙂 <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>
> It is an intent concept<br>
<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 spec).<br></blockquote><div><br></div><div>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).</div><div><br></div><div>It's not a support level concept either (as demonstrated above, once again, it's just to hard to make it useful and fair).</div><div><br></div><div>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.</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>
It also makes little sense to me. We don't know the user intent, so I think <br>
you meant "the app intends to be used for mimetype X", but that's true for all <br>
mimetypes it supports, if no other apps is available for it....<br></blockquote><div><br></div><div>Not sure I understand but maybe. Of course GIMP can start by opening a JPEG for instance. But JPEG is a lossy format, limited to 8 bpc (well there is some 12bpc version theoretically but nobody really uses this), with ugly artifacts and all that. Don't get me wrong: most people edit JPEG but that's definitely not what this format is for. Pro photographers would prefer to open the RAW image for instance into darktable, develop it into an appropriate intermediate format such as TIFF, which GIMP will open. Then JPEG will only be the finale export format.</div><div><br></div><div>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).</div><div>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).</div><div><br></div><div>This is why it is really about intent.</div><div><br></div><div>(note: of course, some people may want to only see XCF through a viewer, and maybe others may always want to open JPEG in GIMP, nothing is impossible; then they have user settings, which already exists; I'm talking about common case of course)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It's all a matter of ordering / priority, IMHO, not intent.<br></blockquote><div><br></div><div>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! 🤪</div><div><br></div><div>Also AFAICT, there is already specs for ordering/priority at desktop-level, and users already have the possibility (in all desktops?) to override these and set their own priority. This already exists. The only thing which doesn't exist is for software developers to give a bit more insight on what their software does (not in term of "preferences" but in term of "intent", because once again, in all good faith, I prefer and use my software. That's only natural! Makes no sense for me to give preferences or priority instructions).<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>
> the intent is not too accurate on purpose, because at some<br>
> point, over-precision doesn't make sense. Yes at some point the user will<br>
> have to choose. For instance the format `.odt` is a valid native format for<br>
> LibreOffice, OpenOffice and Calligra AFAIK, so if you have all 3 installed,<br>
> the default could be any of these (until an explicit user decision).<br>
<br>
This is a good example of why numbers would help compared to only 3 levels.<br>
Even though ODT is the native mimetype for all three, Calligra cannot claim to <br>
be as feature complete (and popular) as LibreOffice/OpenOffice so it would be <br>
reasonable for it to ship with a lower default-preference number.<br></blockquote><div><br></div><div>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!). 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.<br></div><div><br></div><div>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 if the supported features are what they need. Also 2 software can have not a subset of features of one to the other but complementary ones. Feature completeness is really not enough to qualify the software support. Feature-completeness is a mirage, always has been, always will be.<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 completely realize that all this relies on application developers being <br>
reasonable (as you said too),</blockquote><div><br></div><div>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!</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.<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">and that a global ordering (for a given <br>
mimetype) among different communities is quite hard to achieve. So it won't be <br>
perfect either, but as you say, it would be an improvement already, because at <br>
least it will provide a way to solve the issue, in the case where people <br>
agree.<br>
<br>
In summary, I suggest that we combine those two ideas, by documenting ranges <br>
to be used for native mimetypes, for "well supported, makes sense as default" <br>
mimetypes (your PSD example), and for "also supported, but with low preference <br>
by default" mimetypes.<br>
<br>
What I don't know, is how to actually write it out in the application desktop <br>
files.<br>
<br>
Maybe with an [InitialPreference] group where we can write<br>
image/x-xcf=20<br>
image/x-compressed-xcf=20<br>
image/x-psd=10<br>
image/openraster=10<br>
<br>
[and all other mimetypes listed in the MimeType field, would default to 5 or <br>
something like that]<br></blockquote><div><br></div><div>No really the more I look at this numbering idea, the worse it looks to me. I would have seriously no idea how to number most formats. We would end up not using it. That's not good. 🤷<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>
In KDE we made InitialPreference default to 1, and I remember regretting that <br>
choice, it made it impossible to say "should be less than this other app whose <br>
desktop file we don't control and which doesn't use this feature".<br>
<br>
What do you think?<br></blockquote><div>See above. 🙂</div><div><br></div><div>Jehan</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>
-- <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>