Re: New `MimeType` fields in .desktop

[Thayne]

I'd like to point out that on Ubuntu 20.04 there are no system
mimeapps.list files provided (either for DE or globally). I believe
the same is true of archlinux.   Which means that unless the user has
specifically changed the default application for a mime type, if
multiple applications handle a mime type, which one is chosen is,
according to the spec, random. That is clearly not a very good user
experience.  So why aren't mimeapps.list files provided? I don't know
for sure, but as Eli Schwarz said it is rather problematic for a DE or
distribution to decide on what applications should go there for every
possible MIME type, not to mention the problem of the default
application not being installed. It also puts the burden of
maintaining that list on package maintainers rather than distributing
it among applications developers.  An application could potentially
add itself to a mimeapps.list  file, but that also has problems. Which
mimeapps.list files  does it add to? All of them? Just the
distribution-provided non-desktop-specific, just the desktop-specific?
And where does it add it? the end, the beginning? It also needs to be
smart enough to handle the cases of the file not existing, or if it
has additional sections besides [Default Applications].

I'm not sure the original proposal is the best solution, but there is
clearly a problem here.

Thayne McCombs

On Wed, Feb 17, 2021 at 7:17 PM Eli Schwartz  wrote:
>
> On 2/17/21 5:52 PM, Bastien Nocera wrote:
> > The order for mime-types with no defaults has nothing to do with a
> > "shared database", it's implementation specific, as it's not codified
> > in the mime specs. GLib probably behaves differently than Qt does,
> > which means that the file managers using either of those are likely to
> > behave differently.
>
> Qt's native support for opening files in accordance with XDG is to
> invoke /usr/bin/xdg-open.
>
> --
> Eli Schwartz
> Arch Linux Bug Wrangler and Trusted User
>
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Eli Schwartz]

On 2/17/21 5:52 PM, Bastien Nocera wrote:
> The order for mime-types with no defaults has nothing to do with a
> "shared database", it's implementation specific, as it's not codified
> in the mime specs. GLib probably behaves differently than Qt does,
> which means that the file managers using either of those are likely to
> behave differently.

Qt's native support for opening files in accordance with XDG is to
invoke /usr/bin/xdg-open.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User



OpenPGP_signature
Description: OpenPGP digital signature
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Jehan Pagès]

Hi!

On Wed, Feb 17, 2021 at 11:52 PM Bastien Nocera  wrote:

> On Wed, 2021-02-17 at 22:07 +0100, Jehan Pagès wrote:
> > 
> > There is also something which I am not fond of with the order
> > depending on a shared database: we must agree on an order which might
> > not be fair. Say 2 applications are on the exact same action fields,
> > i.e. they both work on the same file formats (for instance JPEG, PNG
> > for image viewers). If the defaults depend on this shared database,
> > then the same one will consistently be the default image viewer
> > shadowing (if installed) all the others. Be it based on character
> > order (then you'd want to just name your app "aaa") or just whatever
> > the database maintainer prefer for oneself, it's not right.
>
> It's not a database, it's a default configuration for various desktops.
> As mentioned in my previous email, it's also likely to be easily
> changed in the "default applications" panel in GNOME, and equivalent
> somewhere else.
>
> > On the other hand, when no order is specified centrally, but each
> > software is able to tell its intent "I'm made to display JPEG, PNG…"
> > without specifying priority relatively to other software, at least we
> > can go with fairer algorithm (something not based on an arbitrary
> > choice making a strict order). Be it "last installed" or "keeping
> > stability to whatever was here first" (then it will likely be
> > dependent on your desktop choice during install, and distrib
> > maintainers, at least not the same on all distributions).
>
> The order for mime-types with no defaults has nothing to do with a
> "shared database", it's implementation specific, as it's not codified
> in the mime specs.


I know. Your quote of mine was me discussing the idea of getting more
logics into a shared database as proposed earlier by Thomas (clearly
looking at the part of I quoted myself doesn't say much of it, it was in
the flow of the discussion). But I'm aware it's not like this currently. I
was only preemptively saying that I'm not fan of this proposed solution to
the problem.


> GLib probably behaves differently than Qt does,
> which means that the file managers using either of those are likely to
> behave differently.
>
> If you want to solve this problem, you'll probably need to figure out
> whether their behaviour is intentional, and then change the specs to
> clarify the intended behaviour.
>

How do we know this? Who will know this if not even you who maintain these
files know this? I think we are all aware that with software going on for
dozens of years, sometimes some of the reasons for things get lost in time.

Now even if it's intentional, I don't think that's such a good behavior
anyway. So I'm not sure it matters too much to know if it is actually
intentional or not.

Which is why I proposed the change from my first email. So far, with all
the discussions which went on, I still believe it is a good solution,
mostly because it scales well. Developers just have to add a bit more of
semantic associations in their desktop file. And then distributions/desktop
can update their no-default algorithm to use this info if it is present.

In particular, a software which set some native and intent MIME types
explicitly says that it is likely not a proper default application for all
the other MIME types it supports (e.g. GIMP is not a proper default for
JPEG handling, neither is LibreOffice the best default for .txt files…).
Oppositely it explicitly says it is a very good fit for whatever is its
native formats, and that it's an appropriate fallback for same-intent
formats if no applications set it as native.

The nice thing is that it requires really not so much change from everyone
and it looks to me it would work quite well here.

Jehan

-- 
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Bollinger, John C]

On Wednesday, February 17, 2021 3:07 PM, Jehan Pagès 
 wrote:

On Wed, Feb 17, 2021 at 8:26 PM Thomas Kluyver 
mailto:tho...@kluyver.me.uk>> wrote:

This particular user reports that *updating* GIMP causes the file association 
to change. That definitely seems like a bug: I can understand that someone 
might want a newly installed app to take over from the previous default, but 
updating shouldn't affect it.

Reading the EndeavourOS thread about it, I think what's happening is that, with 
no default application set, something takes the first application listed in a 
mimeinfo.cache file as the default. It seems like an obvious thing to do. But 
the man page for update-desktop-database (which generates that file) is clear 
that you shouldn't:

> The  order  of  the  desktop  files  found for a MIME type is not 
> significant. Therefore, an external mechanism must be used to determine what  
> is  the  preferred desktop file for a MIME type.

The order of applications in that file is not even currently stable 
(https://gitlab.freedesktop.org/xdg/desktop-file-utils/-/issues/3),
 so each time it's regenerated you could get a different application. But 
simply sorting them would probably put gimp before gwenview, so it wouldn't 
have the result that user wants.

There is also something which I am not fond of with the order depending on a 
shared database: we must agree on an order which might not be fair. Say 2 
applications are on the exact same action fields, i.e. they both work on the 
same file formats (for instance JPEG, PNG for image viewers). If the defaults 
depend on this shared database, then the same one will consistently be the 
default image viewer shadowing (if installed) all the others. Be it based on 
character order (then you'd want to just name your app "aaa") or just whatever 
the database maintainer prefer for oneself, it's not right.

Well yes, that's part of the reason why the specifications explicitly say that 
the mime-info database should not be used for choosing default applications.  
But I suppose that in the event that there is no other viable basis for a 
decision, it provides a last-ditch alternative.

On the other hand, when no order is specified centrally, but each software is 
able to tell its intent "I'm made to display JPEG, PNG…" without specifying 
priority relatively to other software, at least we can go with fairer algorithm 
(something not based on an arbitrary choice making a strict order). Be it "last 
installed" or "keeping stability to whatever was here first" (then it will 
likely be dependent on your desktop choice during install, and distrib 
maintainers, at least not the same on all distributions).

Both of those specific approaches (preferring the most recently or least 
recently installed) can be supported by the XDG MIME Applications specification 
and existing software based on that.  I described how it could be done in a 
previous message.  That would, however, require software providers and / or 
packagers to opt in, either by directly modifying the appropriate mimeapps.list 
file as part of their installation process or by invoking some standard agent 
to do so on their behalf.  It would be preferable to use an agent, as that 
would support applying the chosen approach consistently.  Possibly 
desktop-file-install could be given the responsibility.

That's still mediated by central (and per-user) files, however, so I'm 
uncertain whether you would consider it "specified centrally", which you seem 
to be advocating against.  If you disfavor it on that basis then I'm curious 
what kind of alternative you have in mind.


John




Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Bastien Nocera]

On Wed, 2021-02-17 at 23:02 +, Thomas Kluyver wrote:
> On Wed, 17 Feb 2021, at 22:46, Bastien Nocera wrote:
> > I split it off anyway so that I could stop maintaining the shared-
> > mime-
> > info package and not have anyone who might come in's decisions
> > about
> > what the best default image viewer is impact GNOME. Here's the
> > GNOME
> > configuration:
> > https://src.fedoraproject.org/rpms/gnome-desktop3/blob/rawhide/f/gnome-mimeapps.list
> 
> Aha, thanks. :-) Interestingly, on my (F33 workstation) system,
> /usr/share/applications/mimeapps.list and gnome-mimeapps.list are
> identical. Maybe this is some relic after upgrading through several
> versions. :-/

They're identical because no one's changed the version in shared-mime-
info:
https://src.fedoraproject.org/rpms/shared-mime-info/history/mimeapps.list?identifier=rawhide

___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Bastien Nocera]

On Wed, 2021-02-17 at 22:07 +0100, Jehan Pagès wrote:
> 
> There is also something which I am not fond of with the order
> depending on a shared database: we must agree on an order which might
> not be fair. Say 2 applications are on the exact same action fields,
> i.e. they both work on the same file formats (for instance JPEG, PNG
> for image viewers). If the defaults depend on this shared database,
> then the same one will consistently be the default image viewer
> shadowing (if installed) all the others. Be it based on character
> order (then you'd want to just name your app "aaa") or just whatever
> the database maintainer prefer for oneself, it's not right.

It's not a database, it's a default configuration for various desktops.
As mentioned in my previous email, it's also likely to be easily
changed in the "default applications" panel in GNOME, and equivalent
somewhere else.

> On the other hand, when no order is specified centrally, but each
> software is able to tell its intent "I'm made to display JPEG, PNG…"
> without specifying priority relatively to other software, at least we
> can go with fairer algorithm (something not based on an arbitrary
> choice making a strict order). Be it "last installed" or "keeping
> stability to whatever was here first" (then it will likely be
> dependent on your desktop choice during install, and distrib
> maintainers, at least not the same on all distributions).

The order for mime-types with no defaults has nothing to do with a
"shared database", it's implementation specific, as it's not codified
in the mime specs. GLib probably behaves differently than Qt does,
which means that the file managers using either of those are likely to
behave differently.

If you want to solve this problem, you'll probably need to figure out
whether their behaviour is intentional, and then change the specs to
clarify the intended behaviour.


___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Thomas Kluyver]

On Wed, 17 Feb 2021, at 22:46, Bastien Nocera wrote:
> I split it off anyway so that I could stop maintaining the shared-mime-
> info package and not have anyone who might come in's decisions about
> what the best default image viewer is impact GNOME. Here's the GNOME
> configuration:
> https://src.fedoraproject.org/rpms/gnome-desktop3/blob/rawhide/f/gnome-mimeapps.list

Aha, thanks. :-) Interestingly, on my (F33 workstation) system, 
/usr/share/applications/mimeapps.list and gnome-mimeapps.list are identical. 
Maybe this is some relic after upgrading through several versions. :-/

Thomas
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Bastien Nocera]

On Wed, 2021-02-17 at 19:26 +, Thomas Kluyver wrote:
> One way to address this is to ship a list of default apps - e.g.
> Fedora associates image/jpeg with Eye of Gnome by default. Fedora
> appears to set this regardless of desktop, but the mime-apps spec
> (https://specifications.freedesktop.org/mime-apps-spec/1.0.1/ )
> allows for both desktop specific defaults and a sequence of defaults
> from which it will use the first available.

Not quite. There used to be only one file matching all the desktops for
the longest time, and nobody ever complained because nobody seems to
have run into the problem of launching GNOME apps on KDE because the
GNOME apps were never installed.

I split it off anyway so that I could stop maintaining the shared-mime-
info package and not have anyone who might come in's decisions about
what the best default image viewer is impact GNOME. Here's the GNOME
configuration:
https://src.fedoraproject.org/rpms/gnome-desktop3/blob/rawhide/f/gnome-mimeapps.list

Other files in the same directory will show you how it's made.

GNOME also ships with a "default applications" settings panel which
make sure that, for example, the image viewer selected is the one that
opens all the image types it supports by default.

___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Jehan Pagès]

Hi!

On Wed, Feb 17, 2021 at 8:26 PM Thomas Kluyver  wrote:

> On Wed, 17 Feb 2021, at 18:22, Jehan Pagès wrote:
>
> I do agree it's not so much to start with. Anyway here is the recent
> report: https://gitlab.gnome.org/GNOME/gimp/-/issues/6449
>
>
> Thanks!
>
> This particular user reports that *updating* GIMP causes the file
> association to change. That definitely seems like a bug: I can understand
> that someone might want a newly installed app to take over from the
> previous default, but updating shouldn't affect it.
>
> Reading the EndeavourOS thread about it, I think what's happening is that,
> with no default application set, something takes the first application
> listed in a mimeinfo.cache file as the default. It seems like an obvious
> thing to do. But the man page for update-desktop-database (which generates
> that file) is clear that you shouldn't:
>
> > The  order  of  the  desktop  files  found for a MIME type is not
> significant. Therefore, an external mechanism must be used to determine
> what  is  the  preferred desktop file for a MIME type.
>
> The order of applications in that file is not even currently stable (
> https://gitlab.freedesktop.org/xdg/desktop-file-utils/-/issues/3), so
> each time it's regenerated you could get a different application. But
> simply sorting them would probably put gimp before gwenview, so it wouldn't
> have the result that user wants.
>

There is also something which I am not fond of with the order depending on
a shared database: we must agree on an order which might not be fair. Say 2
applications are on the exact same action fields, i.e. they both work on
the same file formats (for instance JPEG, PNG for image viewers). If the
defaults depend on this shared database, then the same one will
consistently be the default image viewer shadowing (if installed) all the
others. Be it based on character order (then you'd want to just name your
app "aaa") or just whatever the database maintainer prefer for oneself,
it's not right.

On the other hand, when no order is specified centrally, but each software
is able to tell its intent "I'm made to display JPEG, PNG…" without
specifying priority relatively to other software, at least we can go with
fairer algorithm (something not based on an arbitrary choice making a
strict order). Be it "last installed" or "keeping stability to whatever was
here first" (then it will likely be dependent on your desktop choice during
install, and distrib maintainers, at least not the same on all
distributions).

Jehan



> One way to address this is to ship a list of default apps - e.g. Fedora
> associates image/jpeg with Eye of Gnome by default. Fedora appears to set
> this regardless of desktop, but the mime-apps spec (
> https://specifications.freedesktop.org/mime-apps-spec/1.0.1/ ) allows for
> both desktop specific defaults and a sequence of defaults from which it
> will use the first available.
>
> The desktop could (should?) also make a deterministic choice even without
> a default (e.g. sort the desktop files from mimeinfo.cache itself). It
> might be the wrong choice, of course, but a consistent wrong choice and a
> clear way to override it is less frustrating than something that might or
> might not go wrong every time you update it.
>
> Best wishes,
> Thomas
>


-- 
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Jehan Pagès]

Hi,

On Wed, Feb 17, 2021 at 9:43 PM Bollinger, John C 
wrote:

> On Wednesday, February 17, 2021 11:35 AM, Jehan Pagès <
> jehan.marmott...@gmail.com> wrote:
>
> In particular when here the issue is very visible. The desktop format is
> much too broad as to what consists of a MIME type support. It is obvious no
> desktop out there will be able to make reasonable default choices with such
> basic information.
>
>
> Just as I would be open, in principle, to adding some variety of quality
> of support measure to the mime-association information in desktop files, I
> would also be open, in principle, to adding some kind of purpose-based
> categorization of MIME associations.  The two might even work together. but
> I don't see any of that in the proposal that was brought to the table.
>

Please let's stop this part of the discussion here. I already apologized
for having been confrontational and I really meant it.

And everyone in this thread already told you that what you say my proposal
is not is exactly what my proposal is about. You are the only one who is
persistently telling me that you know better than me what I said. This is
just not constructive and neither nice nor respectful. So please let's stop
it here.


> I never denied that there was an issue, but I did and do challenge the
> specific proposal, and I furthermore question to what extent individual
> software packages are positioned to provide good solution, whatever changes
> might be made in the desktop file specification.
>

Then we can discuss the ideas to improve the situation and do better than
my proposal. This is what everyone else is doing, and as you see, the
discussion goes very well with everyone else. On your end, you are just
consistently going off-topic and explaining to me what you think I said,
even when I tell you it's not.

Thanks for understanding and let's go forward now.

Jehan



>
> Regards,
>
> John
>
>
> --
>
> Email Disclaimer: www.stjude.org/emaildisclaimer
> Consultation Disclaimer: www.stjude.org/consultationdisclaimer
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
>


-- 
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Bollinger, John C]

On Wednesday, February 17, 2021 11:35 AM, Jehan Pagès 
 wrote:

I didn't want to answer this email, but some parts are so wrong that I couldn't 
stop 
(https://xkcd.com/386/
 藍).

Ah, one of my favorites.

On Wed, Feb 17, 2021 at 4:13 PM Bollinger, John C 
mailto:john.bollin...@stjude.org>> wrote:
On Wednesday, February 17, 2021 6:30 AM, Thomas Kluyver 
mailto:tho...@kluyver.me.uk>> wrote:
Distinguishing things like 'native' and 'equivalent intent' filetypes seems 
tempting, but I suspect it would end up with a lot of awkward grey areas. If 
this is a problem worth solving, I'd be more inclined to make a numeric 
priority scale, something like the shared-mime-info database uses for assigning 
mimetypes to files (which allows e.g. ODT files to be recognised as ODT rather 
than general zip files).

The problem here is that the application to be used to open files of a 
particular type is not an inherent characteristic of the file type

Maybe not all formats, but for most, of course it is.

"Maybe not for all formats" establishes my point.  There are definitely file 
types, including many of the most commonly used ones, that can reasonably be 
opened by many different applications.  Therefore, the application to be used 
to open a file is not a property of file types.  That some specific file types 
have unique distinctive choices of application could be construed as a property 
of those specific file types, but not as a property of file types in general.

But even in the "unique distinctive choice" case, I do not construe the unique 
choice as a property even of the specific file type, but instead a property of 
the universe of software.  It may be that under the present circumstances there 
happens to be only one program that's a natural choice, but there could be 
others at some point.  For example, suppose I prepare and distribute my own 
full-featured image editing software, and I choose to have it use XCF as its 
native format.  Suppose I expend the resources to produce feature parity with 
the GIMP.  Now, there isn't a clear choice of which application is best to use 
for opening XCF files on a system that has both programs.  But nothing about 
the file type itself is different, so the once-unique choice of application 
must never have been a property of the file type in the first place.

 If you have a XCF or PSD file, of course it is a work file.
 You could just want to display it, but that's the exception. When you want an 
image for display, you will usually export it to a display image format (JPEG, 
PNG, WebP, AVIF… whatever is out there these days).
[...]
Saying the application (or types of application) is not an inherent 
characteristic of the file type is really wrong for most file formats out there 
(there are some exceptions of course).

In the more general and more category-oriented sense I was speaking, I am quite 
right.  And we're talking about a general-purpose facility, so that's the 
direction we should be looking.  XDG is well factored in this sense: it has a 
mechanism for tracking and identifying file types; it has a mechanism for 
tracking and describing the properties of applications; and it has a mechanism 
for managing associating files with applications by file type and assigning 
default applications.  This modularization creates an appropriate separation of 
interests and minimizes unneeded data dependencies, and it is easy to manage 
from a policy perspective, because all the policy control is in one place 
instead of spread over many files.  It is a good design.  That does not mean it 
cannot be improved, but improvements should harmonize with the existing design 
elements.

 Most formats definitely have intents associated with them. There are formats 
for editing, formats for streaming/speed viewing, formats for quality viewing, 
and so on.

Intent is not software application, as my GIMP-clone example demonstrates.

People having an issue and answering them that they are "mischaracterizing the 
problem" is one of the worst responses possible. Basically "don't fix the 
software, fix the user"?

Who said that's how you should respond to people who raise issues?  Certainly 
not me.  That they have mischaracterized the problem is information useful to 
you​ in identifying the most appropriate solutions.  To the user you say, 
"Here's how to fix it" or even "Here's a tool that will fix it for you."  You 
might even add "We're working on it" if you can do so in good faith.

In particular when here the issue is very visible. The desktop format is much 
too broad as to what consists of a MIME type support. It 

Re: New `MimeType` fields in .desktop

[Eli Schwartz]

On 2/17/21 12:46 PM, Thomas Kluyver wrote:
> On Wed, 17 Feb 2021, at 16:42, Jehan Pagès wrote:
>> Yeah the default application on same level of intent is a difficult
>> question, which was why I was not really focusing on it. I'm not
>> sure but it doesn't look like all distributions/desktop do the same
>> thing currently. It would seem that some at least would just set
>> the last installed software as default. This is definitely wrong
>> often, but I can see also how it can make sense to some. I don't
>> actually think there is a single right answer to this problem
>> unfortunately.
> 
> Do you have any idea which distro/desktop prefers the last installed
> application? Maybe a better starting point is to work out what (if
> anything) does that, and if it's intentional.

all distros and all desktops, in my experience.

> I think the problem needs to be pinned down more precisely before we
> can consider any solution. You've presented some mysterious GIMP
> users. What desktops were they using? What distros? Were they new to
> desktop Linux, or old hands with established preferences? How often
> does this come up, and is it increasing or decreasing?

It sounds like the GIMP project has rediscovered *the* classic problem
with the mime-apps specification, which is indeed external to .desktop
files.

Quick review for anyone in the thread that's not familiar with all the
pieces here. There are a couple of different files in play here:

- .desktop files
Defined by
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html
provided by programs, can declare "I am capable of opening X mimetype,
at least as an advanced right-click option". Very specifically provides
no precedence.

- mimeapps.list
Defined by
https://specifications.freedesktop.org/mime-apps-spec/mime-apps-spec-latest.html
provided by *distros* and *DEs*, or defined by the user, declares which
program (from the desktop-entry-spec) to prefer. There are various
different per-user, per-system, or per-DE copies of the file, with
defined precedence.

- mimeinfo.cache
Created by update-desktop-database
Is a cache, should not control any setings.



Now, the problem is that the mime-apps spec in charge of solving the
originally reported problem has a hole you could drive a truck through.
Very explicitly in the specification it declares...

"In the absence of such an entry, the next mimeapps.list is checked.
Once all levels have been checked, if no entry could be found, the
implementations can pick any of the .desktop files associated with the
mimetype, taking into account added and removed associations as per the
next section."

So, if you do not have a mimeapps.list setting for any given filetype,
the spec goes out of its way to say "any application might be chosen at
complete random to handle the request".

This is problematic because file browsers then do exactly that, and
users then report bugs to the GIMP project when GIMP gets randomly chosen.

But wait -- there's more. Why don't users notice this by virtue of
opening a file twice in a row and getting different results each time?

In practice, that is where mimeinfo.cache comes in. What traditionally
happens here is, the implementation wants to choose a program at
complete random to open the file, so it opens up the cache (that is what
caches are for...) to find out which possible options exist. Then, they
use the simplest form of random choice possible: the first listed
application wins.

Ultimately, the "fault" of this glaring user experience bug is in the
update-desktop-database program, which by virtue of generating the cache
is de facto responsible for selecting which program users will see
getting used.

Every time you run update-desktop-database, the mimeinfo.cache will be
regenerated from scratch, with a non-deterministic order.

The GIMP bug report states:

"Every time I upgrade GIMP with pacman, it is set as default for a wide
range of MimeTypes - mostly image files but also a bunch of other stuff."

This is technically true, even more technically untrue, but ultimately
*really* technically just "painfully true".

Every time you upgrade GIMP, update-desktop-database gets run to update
the cache with the possibly-updated gimp.desktop; Also every time you
upgrade, install, or remove any other application which provides a
desktop file. This is reasonable behavior for updating a *cache*. And,
as a side effect, it regenerates the default file opener per mimetype by
way of the RNG.

...

Congratulations, GIMP, on finally joining the club. I feel your pain.
It's the same pain I feel every time someone reports a bug to my distro
for "application X" which, like GIMP, declares a bunch of mimetypes it
"could" be used for but probably should not be the default for. It's
happened a bunch of times over the years.

The problem is IMHO most hilariously noticeable when some innocent
program declares there are certain conditions in which it can handle
"inode/directory", and 

Re: New `MimeType` fields in .desktop

[Thomas Kluyver]

On Wed, 17 Feb 2021, at 18:22, Jehan Pagès wrote:
> I do agree it's not so much to start with. Anyway here is the recent report: 
> https://gitlab.gnome.org/GNOME/gimp/-/issues/6449 

Thanks!

This particular user reports that *updating* GIMP causes the file association 
to change. That definitely seems like a bug: I can understand that someone 
might want a newly installed app to take over from the previous default, but 
updating shouldn't affect it.

Reading the EndeavourOS thread about it, I think what's happening is that, with 
no default application set, something takes the first application listed in a 
mimeinfo.cache file as the default. It seems like an obvious thing to do. But 
the man page for update-desktop-database (which generates that file) is clear 
that you shouldn't:

> The  order  of  the  desktop  files  found for a MIME type is not 
> significant. Therefore, an external mechanism must be used to determine what  
> is  the  preferred desktop file for a MIME type.

The order of applications in that file is not even currently stable 
(https://gitlab.freedesktop.org/xdg/desktop-file-utils/-/issues/3), so each 
time it's regenerated you could get a different application. But simply sorting 
them would probably put gimp before gwenview, so it wouldn't have the result 
that user wants.

One way to address this is to ship a list of default apps - e.g. Fedora 
associates image/jpeg with Eye of Gnome by default. Fedora appears to set this 
regardless of desktop, but the mime-apps spec 
(https://specifications.freedesktop.org/mime-apps-spec/1.0.1/ ) allows for both 
desktop specific defaults and a sequence of defaults from which it will use the 
first available.

The desktop could (should?) also make a deterministic choice even without a 
default (e.g. sort the desktop files from mimeinfo.cache itself). It might be 
the wrong choice, of course, but a consistent wrong choice and a clear way to 
override it is less frustrating than something that might or might not go wrong 
every time you update it.

Best wishes,
Thomas___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Jehan Pagès]

Hi!

On Wed, Feb 17, 2021 at 7:22 PM Jan Tojnar  wrote:

> On Wed, Feb 17, 2021 at 18:52, Jehan Pagès
>  wrote:
> > If by photos, you mean for instance JPEG images, then this is a
> > display format (a very bad one at that, lossy, with ugly display
> > artifacts…). It is meant for viewing, not editing. Of course I am
> > not saying you should not edit it, we all edit JPEG images, I do it
> > too. But it's definitely not meant for being a good photo source for
> > further edit. And most people (even the ones who edit a lot of JPEG,
> > I think) would probably prefer a simple viewer as default action when
> > double-clicking for instance.
>
> I overedited it a bit. Initially, I wrote bitmap images, as screenshots
> in PNG format are the most common type of images that I edit.
>
> > What is the exact interaction you have in mind which would be the
> > consequence of making a viewer/editor differentiation?
>
> For example, to edit a screenshot file in Pictures directory. In
> Nautilus, I currently have to click “open with other application”
> and then find GIMP in the dialogue. I just do not bother and drag the
> file on manually started instance of GIMP instead.
>
> I imagine that if the MIME types in desktop files were annotated with
> intent, Nautilus could run the mime-apps-spec algorithm [1] twice,
> filtering for “view” intent one time and “edit” intent the
> second time, and it could show edit action in the context menu if they
> differ.
>

That's an interesting idea. But then it requires to have the format
view/edit expectation written somewhere so that you know what your
double-click should end up doing: will it run the default view program or
the default edit program for this MIME type?

So basically, what I guess you are proposing is (workflow-wise):

If a MIME type represents a format made for viewing:
- double-clicking/default action will open the default viewing software
associated with this MIME type.
- contextual menu will propose an alternative "Edit" item (which will run
the default edit software associated with this MIME type) and the usual
"Open with another application" to get the full list of associations.

If the MIME type is tagged as being an edit format, then this is obviously
reversed.

That's an interesting idea, though in this case, it requires much more
changes and I'm not sure if it doesn't get too complicated for most people
(who don't read specs), in other words over-engineered. The simpler single
association seems to be much more straightforward.

This was why I took some care so that what I was proposing would not change
at all how people interact with applications (it only gives some hints for
better defaults which is a rather invisible process). It is a dev-visible
only change (and not filling the new fields does not break your desktop
file, so it's even backward compatible).

So I'm not so sure what to think of your proposition (even though it's
interesting).

Jehan


> [1]:
> https://specifications.freedesktop.org/mime-apps-spec/latest/ar01s05.html
>
>
>

-- 
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Jehan Pagès]

Hello!

On Wed, Feb 17, 2021 at 6:46 PM Thomas Kluyver  wrote:

> On Wed, 17 Feb 2021, at 16:42, Jehan Pagès wrote:
>
> Yes! Finally someone who reads emails before answering. :-)
>
>
> I'll just note that this isn't a particularly useful tone in a discussion
> that already feels heated. I actually haven't read your emails particularly
> closely, I just think I've happened to pick up your general idea. ;-)
>

Yes. I'm sorry. I must admit I was a bit frustrated by the original
exchanges and should not have let the steam go. So I apologize John. 

>
> It's an interesting idea, but wouldn't it be very hard to tell? Like if
> someone asked me how much of PSD is supported on GIMP (on a scale, say from
> 0 to 10), I would have no idea where we stand. We do have support, and we
> try to improve it regularly. We also accept patches with arms wide open.
> But how much of it is supported? No idea.
>
>
> I'm not suggesting it would represent exactly how well a format is
> supported. You'd map rough semantic guidelines onto numbers (e.g.
> 100=designed for this file format, 30=can import but not save, 10=can
> extract partial information). Strict categories always get awkward, putting
> them on a scale allows you to be a bit fuzzy about it.
>
> But we're getting ahead of ourselves. Let's discuss problems before
> solutions.
>
> Yeah the default application on same level of intent is a difficult
> question, which was why I was not really focusing on it. I'm not sure but
> it doesn't look like all distributions/desktop do the same thing currently.
> It would seem that some at least would just set the last installed software
> as default. This is definitely wrong often, but I can see also how it can
> make sense to some. I don't actually think there is a single right answer
> to this problem unfortunately.
>
>
> Do you have any idea which distro/desktop prefers the last installed
> application? Maybe a better starting point is to work out what (if
> anything) does that, and if it's intentional.
>

Apparently something called EndeavourOS (this was what used the person who
reported recently reported). But I'm pretty sure that I had similar issues
too by the past (been using Fedora for a few years now, so probably on it).
I just never thought too much of it until now, because I would just
customize the default app and be done with it.

In any case, since there is currently no semantics on file
formats/application association, wouldn't it just happen commonly? We just
don't pay attention to it when we know well how to edit the default
associations anyway. Also we don't install applications all the time… well
at least I don't (just once in a while, I would install something new for
some new usage I have hence often not much overlapping with other software
anyway).


> I think the problem needs to be pinned down more precisely before we can
> consider any solution. You've presented some mysterious GIMP users. What
> desktops were they using? What distros? Were they new to desktop Linux, or
> old hands with established preferences? How often does this come up, and is
> it increasing or decreasing?
>

I do agree it's not so much to start with. Anyway here is the recent
report: https://gitlab.gnome.org/GNOME/gimp/-/issues/6449

But really it's more than just this user which made me come up with this
idea (I'm not **that** dedicated to every bug reporter! ). I mean, yeah
it triggered the thinking, but in the end, that's because I re-read the
desktop format spec and thought it had some obvious (to me at least)
weaknesses regarding the mime type association. I also remembered that I
had the issue once or twice, never thinking much about it until today
(which doesn't mean there is no issue, only that it's easy to work around
when you know your way on your desktop).

I'm not saying it's a huge priority or anything or that it's a
deal-breaker. Just… would be nice to improve. 


> Changing a specification and getting everyone involved to adopt the
> changes is a long, difficult process.
>

I know. I've even contributed to some IETF RFCs by the past. I'm not
looking for a change tomorrow. 


> If there's any chance the problem can be solved (or sufficiently
> mitigated) by changing software without changing the desktop file spec,
> it's worth trying that first.
>

Of course, though I don't think that it's the right idea. If each
desktop/distribution out there uses a different algorithm to process the
desktop files, then it's an endless task (where you have to discuss the
same discussion over and over with different developers). On the other
hand, if it's in the spec with some fields and some recommendation on
usage, then it can just be considered an improvement/bug when updating the
standard.

The other alternative you proposed (extending the shared-mime-info
database) is obviously an interesting one. More interesting than looking up
code of every distribution which processes desktop files, because at least
it's shared work and 

Re: New `MimeType` fields in .desktop

[Jan Tojnar]

On Wed, Feb 17, 2021 at 18:52, Jehan Pagès 
 wrote:
If by photos, you mean for instance JPEG images, then this is a 
display format (a very bad one at that, lossy, with ugly display 
artifacts…). It is meant for viewing, not editing. Of course I am 
not saying you should not edit it, we all edit JPEG images, I do it 
too. But it's definitely not meant for being a good photo source for 
further edit. And most people (even the ones who edit a lot of JPEG, 
I think) would probably prefer a simple viewer as default action when 
double-clicking for instance.


I overedited it a bit. Initially, I wrote bitmap images, as screenshots 
in PNG format are the most common type of images that I edit.


What is the exact interaction you have in mind which would be the 
consequence of making a viewer/editor differentiation?


For example, to edit a screenshot file in Pictures directory. In 
Nautilus, I currently have to click “open with other application” 
and then find GIMP in the dialogue. I just do not bother and drag the 
file on manually started instance of GIMP instead.


I imagine that if the MIME types in desktop files were annotated with 
intent, Nautilus could run the mime-apps-spec algorithm [1] twice, 
filtering for “view” intent one time and “edit” intent the 
second time, and it could show edit action in the context menu if they 
differ.


[1]: 
https://specifications.freedesktop.org/mime-apps-spec/latest/ar01s05.html



___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Jehan Pagès]

Hi!

On Wed, Feb 17, 2021 at 5:15 PM Jan Tojnar  wrote:

> On Wed, Feb 17, 2021 at 15:53, Thomas Kluyver 
> wrote:
> > I can see what you're saying, but I don't think it's ridiculous to
> > suggest that a desktop file could encode some indication of how well
> > an application handles a particular file type. You could think of
> > this as describing 'can open' vs 'can import'.
>
> I agree. In addition to that, there is also viewer vs. editor
> distinction. Sometimes I want to view files but other times I want to
> edit them. These are two different actions and could have different
> applications associated to them, since the editors are optimized for
> editing but not really fit for viewing, and the opposite is true for
> viewers. Unfortunately, the desktop entries do not allow specifying
> more than that the program can “open” a file, which lacks semantic
> subtlety.
>

That's an interesting approach. But since it implies a choice from the
start anyway, we would end up in contextual menu (thinking in term of
default interaction). This is why I was thinking it is better to not do
this and just see the files as their most intended intent (which would be
anyway a viewing or an edition format).


> Here are examples of files I often use in two different modes as a web
> developer:
>
> - HTML file is viewed in Web Browser but edited in a text editor.
>

HTML is  a very interesting special case, because it is one of the
exceptions where it is both a display and an edit format. Then in this
case, it's a hard choice. On one hand since you have more people just
viewing HTML files, it feels perfectly logical to use an HTML viewer
(a.k.a. web browser). On the other hand, normally when you have HTML files
lying around in your local disks (not online!), this is because you are a
developer willing to edit them (though you can save html from a browser and
I could definitely see someone surprised to double-click it later and be
welcome by HTML tags in an editor).

- Photos can be viewed in e.g. Eye of GNOME but edited in GIMP.
>

If by photos, you mean for instance JPEG images, then this is a display
format (a very bad one at that, lossy, with ugly display artifacts…). It is
meant for viewing, not editing. Of course I am not saying you should not
edit it, we all edit JPEG images, I do it too. But it's definitely not
meant for being a good photo source for further edit. And most people (even
the ones who edit a lot of JPEG, I think) would probably prefer a simple
viewer as default action when double-clicking for instance.

What is the exact interaction you have in mind which would be the
consequence of making a viewer/editor differentiation?

Jehan


>
>
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
>


-- 
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Thomas Kluyver]

On Wed, 17 Feb 2021, at 16:42, Jehan Pagès wrote:
> Yes! Finally someone who reads emails before answering. :-)

I'll just note that this isn't a particularly useful tone in a discussion that 
already feels heated. I actually haven't read your emails particularly closely, 
I just think I've happened to pick up your general idea. ;-)

> It's an interesting idea, but wouldn't it be very hard to tell? Like if 
> someone asked me how much of PSD is supported on GIMP (on a scale, say from 0 
> to 10), I would have no idea where we stand. We do have support, and we try 
> to improve it regularly. We also accept patches with arms wide open. But how 
> much of it is supported? No idea.

I'm not suggesting it would represent exactly how well a format is supported. 
You'd map rough semantic guidelines onto numbers (e.g. 100=designed for this 
file format, 30=can import but not save, 10=can extract partial information). 
Strict categories always get awkward, putting them on a scale allows you to be 
a bit fuzzy about it.

But we're getting ahead of ourselves. Let's discuss problems before solutions.

> Yeah the default application on same level of intent is a difficult question, 
> which was why I was not really focusing on it. I'm not sure but it doesn't 
> look like all distributions/desktop do the same thing currently. It would 
> seem that some at least would just set the last installed software as 
> default. This is definitely wrong often, but I can see also how it can make 
> sense to some. I don't actually think there is a single right answer to this 
> problem unfortunately.

Do you have any idea which distro/desktop prefers the last installed 
application? Maybe a better starting point is to work out what (if anything) 
does that, and if it's intentional.

I think the problem needs to be pinned down more precisely before we can 
consider any solution. You've presented some mysterious GIMP users. What 
desktops were they using? What distros? Were they new to desktop Linux, or old 
hands with established preferences? How often does this come up, and is it 
increasing or decreasing?

Changing a specification and getting everyone involved to adopt the changes is 
a long, difficult process. If there's any chance the problem can be solved (or 
sufficiently mitigated) by changing software without changing the desktop file 
spec, it's worth trying that first.

Best wishes,
Thomas___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Jehan Pagès]

Hi!

I didn't want to answer this email, but some parts are so wrong that I
couldn't stop (https://xkcd.com/386/ 藍).

On Wed, Feb 17, 2021 at 4:13 PM Bollinger, John C 
wrote:

> On Wednesday, February 17, 2021 6:30 AM, Thomas Kluyver <
> tho...@kluyver.me.uk> wrote:
>
> Distinguishing things like 'native' and 'equivalent intent' filetypes
> seems tempting, but I suspect it would end up with a lot of awkward grey
> areas. If this is a problem worth solving, I'd be more inclined to make a
> numeric priority scale, something like the shared-mime-info database uses
> for assigning mimetypes to files (which allows e.g. ODT files to be
> recognised as ODT rather than general zip files).
>
> The problem here is that the application to be used to open files of a
> particular type is not an inherent characteristic of the file type
>

Maybe not all formats, but for most, of course it is. If you have a XCF or
PSD file, of course it is a work file. You could just want to display it,
but that's the exception. When you want an image for display, you will
usually export it to a display image format (JPEG, PNG, WebP, AVIF…
whatever is out there these days).
Of course, you can edit from a JPEG/PNG and many people do (me included).
It's completely fine to do this (which is why it is in the open list) but
it's not what these files are made for (they are lossy, yes even PNG is
hugely lossy compared to a work file; they have countless limitations,
etc.). These are final output files not work files, often not even good
source files (pro photographers try not to start from JPEG, they start from
the RAW files).

If you send someone a text for viewing, it could be a PDF for instance. You
send the ODT or OOXML when you want them to edit it. Sure many people just
send ODT/OOXML, and sure you can edit PDF. But that's not the intent.
Same as you send someone a generated PDF, not a LaTeX file, by the way.

If you send someone a .blend file, it's to open in Blender (or maybe
another 3D software which supports importing from Blender format), not to
view the 3D object or the edited scene. If you want to just show a video to
someone, you render a .mov/avi/mp4 or whatever other end-formats.

Saying the application (or types of application) is not an inherent
characteristic of the file type is really wrong for most file formats out
there (there are some exceptions of course). Most formats definitely have
intents associated with them. There are formats for editing, formats for
streaming/speed viewing, formats for quality viewing, and so on. Moreover
even within a given broad intent, you get more specialized sub-category
formats (if you take video formats for viewing for instance, there are so
many formats specialized in some specific fields). Most formats are usually
even created to fill in a specific intent and sometimes specific
applications are created to specialize in the given intent.


> , nor of the set of available applications that can handle that type.
> That's why the user has no good reason to expect stability of default
> application where no specific one is configured.  And it's also why the
> user is mischaracterizing the problem if they claim that the GIMP has taken
> over file associations for a given file type -- installing a desktop file
> simply does not do that, because desktop files express no policy.
>

People having an issue and answering them that they are "mischaracterizing
the problem" is one of the worst responses possible. Basically "don't fix
the software, fix the user"?

In particular when here the issue is very visible. The desktop format is
much too broad as to what consists of a MIME type support. It is obvious no
desktop out there will be able to make reasonable default choices with such
basic information.

I never thought much so far (until we got a recent report about it), but I
do recall I had similar issues by the past. I remembered times when opening
.txt. file would open them in LibreOffice and I had to fix it manually. I
remembered times when some software native format ended up opened by
another application whose native format was another and which didn't even
have a complete support of the other format. And so on.

So no, the user did not mischaracterize anything when one thought that
there was a problem. The computer cannot be in the person's head to handle
special cases, but we can definitely improve the default situation, because
yes both application formats definitely have intent built-in within
themselves.

Jehan

Another approach to the stability issue (e.g. GIMP 'taking over' the JPEG
> mimetype) is for the desktop to fix it: if you open a JPEG file and there
> isn't already a default application for that, store whatever it uses as the
> default application, so it won't change unless the user manually changes
> the association or uninstalls that application. I think that could be done
> without changing any specs.
>
> Yes.  This would be a manifestation of "better tools" such as I suggested

Re: New `MimeType` fields in .desktop

[Jehan Pagès]

On Wed, Feb 17, 2021 at 5:32 PM Bollinger, John C 
wrote:

> On Wednesday, February 17, 2021 9:53 AM, Thomas Kluyver <
> tho...@kluyver.me.uk> wrote:
>
> I can see what you're saying, but I don't think it's ridiculous to suggest
> that a desktop file could encode some indication of how well an application
> handles a particular file type. You could think of this as describing 'can
> open' vs 'can import'. A few more examples from my laptop of technically
> possible matches that you probably wouldn't want to be used by default:
>
>
>- Libreoffice Writer & text/plain
>   - Libreoffice Draw & application/pdf
>   - Pinta (bitmap graphics editor) & image/svg
>   - File roller (archive manager) & application/x-chrome-extension
>
> I don't have a problem in principle with giving desktop files a way to
> express a quality of support measure for the various MIME types they can
> handle.  That's about the capabilities of the software, not about system
> policy, notwithstanding that tools that implement policy could rely on such
> data in making decisions.  But that's qualitatively different from Jehan's
> proposal as I understand it.
>

You didn't understand. Thomas and Jan's answers are spot-on the kind of
discussions I was looking for by posting here. They perfectly understood
the proposition, whereas your answers are quite off-topic. Cf. my earlier
email, where I tell your answer is confusing and that you didn't
understand, but you just went on going even more off-topic assuming or
talking about unrelated stuff.

Jehan


> In particular, I don't envision that if such a mechanism were implemented
> in the spec and software, and used as intended by the GIMP, that it would
> in fact satisfactorily resolve the issue that motivated the proposal.
>
> In my experience, things like this haven't really come up, so I'm inclined
> to agree with you that it doesn't warrant changing the standard. But I
> think it's better to understand what's specifically going wrong and work
> out how else it can be improved, rather than insisting that this could
> never be part of a desktop file. Labelling options with some kind of
> priority is compromise we live with in various places.
>
>
> I am all for understanding the problem and its context in order to find an
> appropriate solution.  It is based on my present understanding of the
> context that I persist in asserting that desktop files should not express
> policy.  I don't see anything in the specific problem presented that
> challenges that position as far as I am concerned, and I am having trouble
> imagining what sort of thing would.  In short: although firm, my position
> is analytical, not dogmatic.
>
>
> John
>
>
> --
>
> Email Disclaimer: www.stjude.org/emaildisclaimer
> Consultation Disclaimer: www.stjude.org/consultationdisclaimer
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
>


-- 
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Jehan Pagès]

Hi!

On Wed, Feb 17, 2021 at 1:30 PM Thomas Kluyver  wrote:

> On Tue, 16 Feb 2021, at 23:04, Bollinger, John C wrote:
>
> But that does not imply that some applications should be able to claim to
> be more equal than others with respect to particular file types.
>
>
> I think Jehan's idea is that applications should be able to claim to be
> *less* equal than others for a given mimetype, i.e. that GIMP could declare
> 'I can open JPEGs, but you should probably use something else by default'.
> Obviously, if the user explicitly set GIMP as the default handler for
> image/jpeg, it would override this priority.
>

Yes! Finally someone who reads emails before answering. :-)

Distinguishing things like 'native' and 'equivalent intent' filetypes seems
> tempting, but I suspect it would end up with a lot of awkward grey areas.
> If this is a problem worth solving, I'd be more inclined to make a numeric
> priority scale, something like the shared-mime-info database uses for
> assigning mimetypes to files (which allows e.g. ODT files to be recognised
> as ODT rather than general zip files).
>

It's an interesting idea, but wouldn't it be very hard to tell? Like if
someone asked me how much of PSD is supported on GIMP (on a scale, say from
0 to 10), I would have no idea where we stand. We do have support, and we
try to improve it regularly. We also accept patches with arms wide open.
But how much of it is supported? No idea.
And I'm pretty sure that unless some type were your native format (either
because you created it, or decided to make it your own native format too),
most applications out there would not be able to say exactly where they are
on a scale, since their focus is elsewhere (creating the best application
supported by its own format). This means that what most devs would set for
their support of many formats would be very approximate. Thus if it's later
used to determine which should be the best defaults, it would not be
actually fair.

What we can say is that PSD is a format with a somewhat similar intent
(raster image editing work-in-progress format) and that we have some ok
support of it.

The other risky issue of comparing support with a scale is that some
software may actually have a not-perfect support yet still be completely
intended for a format. Typically if not mistaken, LibreOffice, OpenOffice,
Calligra all have OpenDocument as their native formats. Yet maybe one of
them misses the support of specific features (I have no idea if true, but
would not be impossible). Therefore say this one application sets a support
at 9 whereas the other would have support at 10. It would not be fair
because their intent matters most here IMO. If they all intend to support
ODT as native format, it is very likely that if someone installs any of
them, they are still fit as good default ODT editor.

This is the reason why I went with semantic fields rather than scale-based
fields. I think that intent matters most here. "What is your program
actually for?"

Nevertheless if we wanted to have some types of scaling (I would say,
additionally to the intent-based semantics), I would go for
approximate/named ones, not numeric based for the reasons cited above. Like
"Perfect" (you can open any file), "Very Good", "Good", "Average" and so
on. Then we could probably situate GIMP's PSD support there (and even so,
not so sure, I'd hesitate between Average and Good nowadays; even this, it
depends on people anyway; for many usage, our support is good, but for
people needing specific features which GIMP doesn't provide, they would
consider our PSD support as bad. As I said, situating non-native support on
a scale is a lot more difficult that one would imagine).


> Another approach to the stability issue (e.g. GIMP 'taking over' the JPEG
> mimetype) is for the desktop to fix it: if you open a JPEG file and there
> isn't already a default application for that, store whatever it uses as the
> default application, so it won't change unless the user manually changes
> the association or uninstalls that application. I think that could be done
> without changing any specs.
>

Yeah the default application on same level of intent is a difficult
question, which was why I was not really focusing on it. I'm not sure but
it doesn't look like all distributions/desktop do the same thing currently.
It would seem that some at least would just set the last installed software
as default. This is definitely wrong often, but I can see also how it can
make sense to some. I don't actually think there is a single right answer
to this problem unfortunately.

IMO adding some semantics on the file association intent is a good
compromise (hence my proposal), but we may not have better hints than
these. You may have several applications installed with the same native
format. Then which should be the default? Impossible to answer (only the
user can). You may have no application using a given format as native, but
several applications with similar intent 

Re: New `MimeType` fields in .desktop

[Bollinger, John C]

On Wednesday, February 17, 2021 9:53 AM, Thomas Kluyver  
wrote:
I can see what you're saying, but I don't think it's ridiculous to suggest that 
a desktop file could encode some indication of how well an application handles 
a particular file type. You could think of this as describing 'can open' vs 
'can import'. A few more examples from my laptop of technically possible 
matches that you probably wouldn't want to be used by default:

 *   Libreoffice Writer & text/plain
 *   Libreoffice Draw & application/pdf
 *   Pinta (bitmap graphics editor) & image/svg
 *   File roller (archive manager) & application/x-chrome-extension

I don't have a problem in principle with giving desktop files a way to express 
a quality of support measure for the various MIME types they can handle.  
That's about the capabilities of the software, not about system policy, 
notwithstanding that tools that implement policy could rely on such data in 
making decisions.  But that's qualitatively different from Jehan's proposal as 
I understand it.  In particular, I don't envision that if such a mechanism were 
implemented in the spec and software, and used as intended by the GIMP, that it 
would in fact satisfactorily resolve the issue that motivated the proposal.

In my experience, things like this haven't really come up, so I'm inclined to 
agree with you that it doesn't warrant changing the standard. But I think it's 
better to understand what's specifically going wrong and work out how else it 
can be improved, rather than insisting that this could never be part of a 
desktop file. Labelling options with some kind of priority is compromise we 
live with in various places.

I am all for understanding the problem and its context in order to find an 
appropriate solution.  It is based on my present understanding of the context 
that I persist in asserting that desktop files should not express policy.  I 
don't see anything in the specific problem presented that challenges that 
position as far as I am concerned, and I am having trouble imagining what sort 
of thing would.  In short: although firm, my position is analytical, not 
dogmatic.


John




Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Jan Tojnar]

On Wed, Feb 17, 2021 at 15:53, Thomas Kluyver  
wrote:
I can see what you're saying, but I don't think it's ridiculous to 
suggest that a desktop file could encode some indication of how well 
an application handles a particular file type. You could think of 
this as describing 'can open' vs 'can import'.


I agree. In addition to that, there is also viewer vs. editor 
distinction. Sometimes I want to view files but other times I want to 
edit them. These are two different actions and could have different 
applications associated to them, since the editors are optimized for 
editing but not really fit for viewing, and the opposite is true for 
viewers. Unfortunately, the desktop entries do not allow specifying 
more than that the program can “open” a file, which lacks semantic 
subtlety.


Here are examples of files I often use in two different modes as a web 
developer:


- HTML file is viewed in Web Browser but edited in a text editor.
- Photos can be viewed in e.g. Eye of GNOME but edited in GIMP.



___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Thomas Kluyver]

On Wed, 17 Feb 2021, at 15:06, Bollinger, John C wrote:
> Ok, on re-reading I can see that, but it is even less the GIMP's role to say 
> "you should prefer other applications for opening JPEGs" than it is to say 
> "you should prefer me for opening XCFs".  Desktop files still are not the 
> right place to express policy.

I can see what you're saying, but I don't think it's ridiculous to suggest that 
a desktop file could encode some indication of how well an application handles 
a particular file type. You could think of this as describing 'can open' vs 
'can import'. A few more examples from my laptop of technically possible 
matches that you probably wouldn't want to be used by default:
 * Libreoffice Writer & text/plain
 * Libreoffice Draw & application/pdf
 * Pinta (bitmap graphics editor) & image/svg
 * File roller (archive manager) & application/x-chrome-extension
In my experience, things like this haven't really come up, so I'm inclined to 
agree with you that it doesn't warrant changing the standard. But I think it's 
better to understand what's specifically going wrong and work out how else it 
can be improved, rather than insisting that this could never be part of a 
desktop file. Labelling options with some kind of priority is compromise we 
live with in various places.

Thomas___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Bollinger, John C]

On Wednesday, February 17, 2021 6:30 AM, Thomas Kluyver  
wrote:

On Tue, 16 Feb 2021, at 23:04, Bollinger, John C wrote:
But that does not imply that some applications should be able to claim to be 
more equal than others with respect to particular file types.

I think Jehan's idea is that applications should be able to claim to be *less* 
equal than others for a given mimetype, i.e. that GIMP could declare 'I can 
open JPEGs, but you should probably use something else by default'. Obviously, 
if the user explicitly set GIMP as the default handler for image/jpeg, it would 
override this priority.

Ok, on re-reading I can see that, but it is even less the GIMP's role to say 
"you should prefer other applications for opening JPEGs" than it is to say "you 
should prefer me for opening XCFs".  Desktop files still are not the right 
place to express policy.  The MIME Applications specification still describes 
the right place(s).

If neither the user nor the system has explicitly configured any default 
application for a given MIME type then it is not reasonable for the user to 
expect the default application for that type to be stable.  If that presents a 
problem for the user then XDG already has a solution: configure their preferred 
default explicitly.  If doing so is unreasonably difficult in some XDG-based 
environment then what is needed is better tools for that environment, not 
changes to the desktop file specification (and all the tools based on it).

Distinguishing things like 'native' and 'equivalent intent' filetypes seems 
tempting, but I suspect it would end up with a lot of awkward grey areas. If 
this is a problem worth solving, I'd be more inclined to make a numeric 
priority scale, something like the shared-mime-info database uses for assigning 
mimetypes to files (which allows e.g. ODT files to be recognised as ODT rather 
than general zip files).

The problem here is that the application to be used to open files of a 
particular type is not an inherent characteristic of the file type, nor of the 
set of available applications that can handle that type.  That's why the user 
has no good reason to expect stability of default application where no specific 
one is configured.  And it's also why the user is mischaracterizing the problem 
if they claim that the GIMP has taken over file associations for a given file 
type -- installing a desktop file simply does not do that, because desktop 
files express no policy.

Another approach to the stability issue (e.g. GIMP 'taking over' the JPEG 
mimetype) is for the desktop to fix it: if you open a JPEG file and there isn't 
already a default application for that, store whatever it uses as the default 
application, so it won't change unless the user manually changes the 
association or uninstalls that application. I think that could be done without 
changing any specs.

Yes.  This would be a manifestation of "better tools" such as I suggested 
above.  It would be an appropriate way to address the issue from the XDG side.


John



From: xdg  on behalf of Thomas Kluyver 

Sent: Wednesday, February 17, 2021 6:30 AM
To: xdg 
Subject: Re: New `MimeType` fields in .desktop

Caution: External Sender. Do not open unless you know the content is safe.

On Tue, 16 Feb 2021, at 23:04, Bollinger, John C wrote:
But that does not imply that some applications should be able to claim to be 
more equal than others with respect to particular file types.

I think Jehan's idea is that applications should be able to claim to be *less* 
equal than others for a given mimetype, i.e. that GIMP could declare 'I can 
open JPEGs, but you should probably use something else by default'. Obviously, 
if the user explicitly set GIMP as the default handler for image/jpeg, it would 
override this priority.

Distinguishing things like 'native' and 'equivalent intent' filetypes seems 
tempting, but I suspect it would end up with a lot of awkward grey areas. If 
this is a problem worth solving, I'd be more inclined to make a numeric 
priority scale, something like the shared-mime-info database uses for assigning 
mimetypes to files (which allows e.g. ODT files to be recognised as ODT rather 
than general zip files).

Another approach to the stability issue (e.g. GIMP 'taking over' the JPEG 
mimetype) is for the desktop to fix it: if you open a JPEG file and there isn't 
already a default application for that, store whatever it uses as the default 
application, so it won't change unless the user manually changes the 
association or uninstalls that application. I think that could be done without 
changing any specs.

Thomas



Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: New `MimeType` fields in .desktop

[Thomas Kluyver]

On Tue, 16 Feb 2021, at 23:04, Bollinger, John C wrote:
> But that does not imply that some applications should be able to claim to be 
> more equal than others with respect to particular file types.

I think Jehan's idea is that applications should be able to claim to be *less* 
equal than others for a given mimetype, i.e. that GIMP could declare 'I can 
open JPEGs, but you should probably use something else by default'. Obviously, 
if the user explicitly set GIMP as the default handler for image/jpeg, it would 
override this priority.

Distinguishing things like 'native' and 'equivalent intent' filetypes seems 
tempting, but I suspect it would end up with a lot of awkward grey areas. If 
this is a problem worth solving, I'd be more inclined to make a numeric 
priority scale, something like the shared-mime-info database uses for assigning 
mimetypes to files (which allows e.g. ODT files to be recognised as ODT rather 
than general zip files).

Another approach to the stability issue (e.g. GIMP 'taking over' the JPEG 
mimetype) is for the desktop to fix it: if you open a JPEG file and there isn't 
already a default application for that, store whatever it uses as the default 
application, so it won't change unless the user manually changes the 
association or uninstalls that application. I think that could be done without 
changing any specs.

Thomas___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg