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
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
