New `MimeType` fields in .desktop

[Eli Schwartz]

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

-------------- 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/20210503/feffca8a/attachment.sig>