Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On 9/20/21 15:04, Elsie Hupp wrote: > As far as I know RFC 1855 is not part of any accepted email > specification—i.e. the ones actually used by the more popular email > clients—and several of the behaviors encouraged in it lead to > undefined behavior on adaptive devices that did not exist in 1995, > such as smartphones. > > Intentionally using formatting that breaks on the vast majority of > computing devices in use is not “good etiquette”; this behavior is > pedantic, condescending, and passive-aggressive, all attributes that > directly violate the Freedesktop Community Standards, which are a > much more important document than your dusty cultural artifact: The fact that smartphone applications are ill designed is not really an indictment on any particular behavior. They also are lead contenders in behavior such as: - adding advertisements for the app you used into your signature - top quoting the entire email thread, recursively Anyway. Your school of thought is in conflict with another school of thought, both schools of thought have wide support in society, and for someone who is so upset at the thought of people acting "pedantic, condescending and passive-aggressive" I find it intriguing that you insult people right back by calling an *extremely* common convention in technical mailing lists, a "dusty cultural artifact" and suggesting that it is malicious behavior. For the record, my cramped smartphone computing device has no problem rendering Peter's excellently well-formatted quotes, but yours are, to me, unreadable. On the other hand, your non-quote content is *mildly* more readable than Peter's hard line wrapping, but not by very much -- both are relatively quite readable. The real issue that basically destroys my ability to parse your replies is the fact that it's essentially impossible to visually distinguish between quotes and original content. The quotes are just a paragraph beginning with a ">" on the first (reflowed) line only. My desktop client converts both of them to indented blockquotes... but perhaps Google / Gmail doesn't have enough funds to pay for developers as talented as the ones Thunderbird has? I genuinely have no idea, this has always been a real puzzler to me. > I’m CCing the conduct committee as a way of *gently encouraging you* > to approach this forum in a modicum of good faith. > > Note: this is all good-faith, constructive criticism of your > behavior, not your character. As such I’m sure it should be no great > difficulty for you to take it to heart. I am sure we are all delighted to know that disagreeing over mailing list etiquette "with intent to make smartphones do worse rendering of the messages" is the point at which you believe it is necessary to summon the code of conduct committee in order to report passive-aggressive condescension. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On 9/20/21 12:03, Peter White wrote: > The way I see it there will be two universes: FHS and a subtly different > XDG Base Dir Spec, which breaks with the former in peculiar subtle ways > and any dev used to the former is in for some surprises, when not > reading carefully. Now, I get that by saying "information" instead of > "files" the authors did not want to limit themselves or the spec to > files, which makes sense, given the elaborations about reading config > files, let aside that it has been done since long before XDG anyways by > shells for example. I think some people would do good by reading and > understanding what was there already before "fixing" things that were > not broken in the first place. This "information" vs. "files" stuff > seems like one of these occasions. > > [...] > > There is no need for a new spec to make this happen since this is > documented in shell manuals which were there from the beginning of time, > UNIX time that is. > > And, need I remind anyone: "Those who do not understand UNIX are > condemned to reinvent it, poorly." -- Henry Spencer > A lot of thought went into it, so one should not go fixing stuff that > was never broken. http://lists.busybox.net/pipermail/busybox/2010-December/074114.html Did you say something about the sacred Unix? Who is reinventing what now? -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: New `MimeType` fields in .desktop
On 5/3/21 8:40 AM, David Faure wrote: > I understand. But then, if > * the distro doesn't want to choose > * the user hasn't made any specific choice > * the application developers are not the best candidate for choosing > then who remains? :) I do in fact have a proposal! Step 1) In the mime apps spec, remove: 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. And replace it with: Once all levels have been checked, if no entry could be found, the implementations MUST query the user to pick one of the .desktop files associated with the mimetype, taking into account added and removed associations as per the next section. Optionally, the implementation may and probably should then default to saving this to "user overrides (recommended location for user configuration GUIs)". Step 2) In the xdg-open program, update open_generic() to comply with the new version of the mime apps spec, by e.g. spawning a zenity selection dialog. If zenity is not installed, a CLI dialog could be printed, but this won't work well if stdout is not a tty... I believe that KDE has a native equivalent to zenity but I'm not sure what that is, and anyway open_generic is particularly for the case where you're not running a recognizable DE, or are running anything other than KDE and the native opener is not installed. Step 3) Open feature requests for DE-specific openers to implement the new version of the mime apps spec. Step 4) Bask in the gratefulness of people who no longer get surprising behavior but are instead asked what they want. ... This change may very well obsolete much of the micro industry that has grown up around xdg-open, where the sole purpose of a program is to provide an alternative xdg-open that does not respect the xdg mimeapps spec, but uses custom rules (generally a mix of regex and desktop entry hints) and prompts the user on ambiguity, because their authors are positive that xdg-open is the literal devil and will never open the right thing ever. Because people don't understand how "the implementations can pick any" works, or they do understand it and it horrified them so much that they ran screaming in the opposite direction. :) And then there is mimeo, a program that lets you take a desktop file and add default associations for it, for every mimetype matching, say, 'glob:text/*'. Because if you don't whack mimeapps.list with a big stick and add user preferences for every mimetype known to man, you might end up in the tragic situation where some implementation of some spec tries to randomly guess for you, so let's better set all the ones you don't use just in case someday you do use it. "Better safe than sorry." > In the end I think > 1) desktop environments can provide a mimeapps-$desktop.lst for distros to use They could, but this is IMO only suitable for mimetypes like inode/directory, about which I'll once more repeat my very early statements in this thread: > 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. For inode/directory, it's indeed appropriate for a DE to assume anyone running this DE will be using this file browser too (and the file browser must be installed as a dependency regardless). > 2) users will still have to do some adjustments, especially when using > distros > who didn't want to decide for them. I'm very much in favor of users doing some adjustments! But they need to be prompted into doing adjustments whenever those adjustments are relevant, rather than letting the spec permit implementations to mistreat the user and do the wrong thing. > The old debate of View vs Edit doesn't really solve this, as someone > mentioned > here, different apps have different features, which goes far beyond View or > Edit. It's just a very limited attempt to add even more confusing rules to auto-guess the user's intent rather than biting the bullet and *asking* them. So, unsurprisingly, it has shortcomings and different scopes which
Re: New `MimeType` fields in .desktop
On 5/3/21 5:58 AM, David Faure wrote: > On jeudi 18 février 2021 03:17:45 CEST 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. > > The actual code for choosing preferred applications for a mimetype, in the Qt/ > KDE world, isn't in Qt, but in KDE Frameworks (KService). That seems highly unlikely. The Qt world can't possibly depend on the KDE world, because KDE builds on Qt rather than Qt building on KDE. So applications using Qt for cross-platform application programming, which aren't KDE applications, will not suddenly go link in KService. In fact, like I said immediately above, Qt's native facility here is QDesktopServices::openUrl() which invokes xdg-open. xdg-open then checks various things to probe for your currently running DE, and... If that DE is some version of kde it will run kde-open or kfmclient. If that DE is gnome, then "the Qt world" will be running a program that then runs "gio open", and hence the actual code for choosing preferred applications in the Qt world isn't in Qt, but in GLib. I chose my words very carefully in response to "GLib probably behaves differently than Qt does" by pointing out that Qt in fact does nothing, but I assumed people know that xdg-open defers to GLib if you're logged into gnome, and defers to KDE frameworks if you're logged into KDE. > I'm late to this thread, but before we talk about adding even more complexity > to the solution of choosing an app for a mimetype, I'd like to understand why > https://specifications.freedesktop.org/mime-apps-spec/latest/ > doesn't solve the issue. If the distro's mimeapps.lst says > image/jpeg=gwenview.desktop;gimp.desktop; > then JPEG files will be opened in gwenview (if installed) rather than in GIMP, I mentioned this earlier in the thread, repeating here: > 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. Yes, I'm on the packaging team for a Linux distro that declines to be put in the position of being an arbiter of good taste. Don't look to us to choose preferred mimeapps.lst applications, we refuse. Even if we wanted to do it, we would be required to provide a mimeapps.lst defining preferences for several dozens of applications per mimetype, and any time a hundred different people add a new program to the repositories we'd need to update this list, and then at the end of the day users are going to have GIMP plus an unofficial user package (the "AUR" / Arch User Repository) and GIMP is still going to be the first on the list somehow for these last-resort-only mimetypes, and the complaints will be fewer but never actually go away. -- 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
On 2/21/21 11:10 AM, Eli Schwartz wrote: > On 2/21/21 10:56 AM, Sebastian Pipping wrote: >> we had exactly that in Gentoo where Gimp was taking over PDF files by >> default, just because it can import PDF and hence announced that mime >> type as supported. >> >> For Gentoo, my workaround was to rename gimp.desktop to zzz-gimp.desktop >> during installation, and that's still done today [1], but it's nowhere >> near a fix and not without problems [2]. >> >> So if you get that situation improved, that would surely be nice. > > Never mind whether that's a bad workaround or a good workaround. How was > that even *a* workaround in the first place? mimeinfo.cache is not > ordered by filename. > > Your "workaround" should be precisely as effective as standing on one > foot and singing The Hedgehog Song. ... Correction: at least as of 2011. As noted in https://gitlab.freedesktop.org/xdg/desktop-file-utils/-/issues/3 just the other day... this was finally "fixed" to at least deterministically order results by filename. 8 years later. destop-file-utils 0.24, released July 2019, has the relevant commit, intended to help reproducible builds rather than the current issue under discussion. At least consecutive re-runs of update-desktop-database with no system changes should not shuffle the defaults anymore. Unfortunately it still doesn't preserve insertion order, so installing new applications will still (deterministically) change the defaults. That workaround now does something (it marks GIMP as very low priority for *all* mimetypes). -- 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
On 2/21/21 10:56 AM, Sebastian Pipping wrote: > we had exactly that in Gentoo where Gimp was taking over PDF files by > default, just because it can import PDF and hence announced that mime > type as supported. > > For Gentoo, my workaround was to rename gimp.desktop to zzz-gimp.desktop > during installation, and that's still done today [1], but it's nowhere > near a fix and not without problems [2]. > > So if you get that situation improved, that would surely be nice. Never mind whether that's a bad workaround or a good workaround. How was that even *a* workaround in the first place? mimeinfo.cache is not ordered by filename. Your "workaround" should be precisely as effective as standing on one foot and singing The Hedgehog Song. -- 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
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
#x27;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 xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
