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

Sat May 8 12:53:39 UTC 2021

Hi!

On Sat, May 8, 2021 at 11:18 AM David Faure <faure at kde.org> wrote:

> On lundi 3 mai 2021 15:36:05 CEST Jehan Pagès wrote:
> > Now if we comes into PSD or ORA files, these are not GIMP's native files,
> > but they have clearly similar intent and since we support it, yes GIMP
> is a
> > very sane choice too (but if Photoshop were on Linux for instance, I
> would
> > say it should advertize to be about editing PSD, hence take precedence
> when
> > installed).
>
> I see. Basically you're defining three levels of initial preference,
> level 2 for native mimetypes, level 1 for "it makes sense to use this app
> for
> these mimetypes too, by default", level 0 for "supported, but should have
> low
> priority".
>
> 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.

>
> So, why not go for an actual number, like the InitialPreference key that
> KDE
> has had forever? It is the same idea, but more expressive because apps can
> be
> ordered along a larger scale. We can still document that "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 [I'm trying to explain
> your
> IntentMimeType key here, but probably not doing a good job at it], then it
> should be below 10".
>

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:

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

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!

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.

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.

> The number should be per-mimetype though, unlike KDE's old
> InitialPreference
> key which is global to the desktop file (oops, that was a bad idea).
>

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.

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.

> > Finally we can open various end-formats (PNG, JPEG, WebM, and a few
> dozens
> > more…) so GIMP advertizes it in its desktop file. It's important because
> it
> > allows GIMP to be in the proposed secondary software (commonly
> right-click
> > menu item "open with") which makes life easier to people; and also
> because
> > in worst case when no other software can view some image format, even if
> > you don't want to edit it, at least you can view it in GIMP as a fallback
>
> Yes.
>
> > This is not a GIMP-only situation. I remember cases in my experience
> where
> > LibreOffice would open .txt files (like what?!) and other similar weird
> > events. Right now, we are in this situation where the default is
> regularly
> > just weird and there have been various reports of this for years.
>
> Yes.
>
> This is why org.kde.kwrite.desktop has InitialPreference=8
> and writer.desktop has InitialPreference=5.
>
> > So my proposition is not about View vs Edit, please read it.
>
> Yes, sorry, I was only referring to old suggestions prompted by the
> reduced
> reasoning of "I don't want to use gimp to view a PNG file, let's
> distinguish
> view and edit". Let's move on.
>
No prob! 🙂

>
> > It is an intent concept
>
> 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).

It's not a support level concept either (as demonstrated above, once again,
it's just to hard to make it useful and fair).

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.

> It also makes little sense to me. We don't know the user intent, so I
> think
> you meant "the app intends to be used for mimetype X", but that's true for
> all
> mimetypes it supports, if no other apps is available for it....
>

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.

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.

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

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

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

> > the intent is not too accurate on purpose, because at some
> > point, over-precision doesn't make sense. Yes at some point the user will
> > have to choose. For instance the format `.odt` is a valid native format
> for
> > LibreOffice, OpenOffice and Calligra AFAIK, so if you have all 3
> installed,
> > the default could be any of these (until an explicit user decision).
>
> This is a good example of why numbers would help compared to only 3 levels.
> Even though ODT is the native mimetype for all three, Calligra cannot
> claim to
> be as feature complete (and popular) as LibreOffice/OpenOffice so it would
> be
> reasonable for it to ship with a lower default-preference number.
>

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.

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.

> I completely realize that all this relies on application developers being
> reasonable (as you said too),

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!

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.

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.

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.

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.

and that a global ordering (for a given
> mimetype) among different communities is quite hard to achieve. So it
> won't be
> perfect either, but as you say, it would be an improvement already,
> because at
> least it will provide a way to solve the issue, in the case where people
> agree.
>
> In summary, I suggest that we combine those two ideas, by documenting
> ranges
> to be used for native mimetypes, for "well supported, makes sense as
> default"
> mimetypes (your PSD example), and for "also supported, but with low
> preference
> by default" mimetypes.
>
> What I don't know, is how to actually write it out in the application
> desktop
> files.
>
> Maybe with an [InitialPreference] group where we can write
> image/x-xcf=20
> image/x-compressed-xcf=20
> image/x-psd=10
> image/openraster=10
>
> [and all other mimetypes listed in the MimeType field, would default to 5
> or
> something like that]
>

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

> In KDE we made InitialPreference default to 1, and I remember regretting
> that
> choice, it made it impossible to say "should be less than this other app
> whose
> desktop file we don't control and which doesn't use this feature".
>
> What do you think?
>
See above. 🙂

Jehan

> --
> 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/a82d2235/attachment-0001.htm>