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 <[email protected]> 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 <[email protected]> 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, [email protected], http://www.davidfaure.fr > Working on KDE Frameworks 5 > > > > _______________________________________________ > xdg mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/xdg > _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
