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 render these definitions confusing... all of which could be solved by not asking the application vendor, but asking the user instead. -- 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