New `MimeType` fields in .desktop

Wed Feb 17 20:06:04 UTC 2021

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 then it mysteriously hijacks the job of the file
browser itself.

https://bugs.archlinux.org/task/30034
https://bugs.archlinux.org/task/54894#comment159599
https://bugs.archlinux.org/task/35528#comment162294

The workaround is for:
- a DE to define preferred default handlers in $DE-mimeapps.list
- an OS to define preferred default handlers in mimeapps.list

The former is, well, kind of a solution, you can at least solve the
inode/directory problem by force-associating the DE's native file
browser for this one mimetype. You can also solve it for any flagship
applications shipped by the DE, though that's more iffy because maybe
people don't install the flagship programs.

The latter is only a solution for e.g. Ubuntu, where a carefully curated
selection of flagship applications shipped by the *OS* instead of the
DE, are present. You thereby attain a specific look and feel intended by
the Ubuntu desktop team, and consistently get pointed to their preferred
application.

None of this scales well, at all, especially not for mimetypes that are
even slightly off the beaten path.

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

IMHO the solution has nothing to do with desktop files, but instead,
"the implementations can pick" should be repealed. Implementations i.e.
opener programs like a file browser, or xdg-open, should NOT assume
anything, but instead interactively prompt the user from a list of
eligible programs, and offer to save that choice as a user preference.

I guess the spec doesn't actually forbid an implementation from doing
that, but I don't know of any that do. They probably assume Ubuntu will
solve the problem by hardcoding an ISV override. I would prefer it if
the spec required, or at least strongly urged the implementation to do so.

At least the latter would raise awareness and people could avoid the
implementations which don't, like the plague.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20210217/3759a9f3/attachment-0001.sig>