New `MimeType` fields in .desktop

[Thomas Kluyver]

On Mon, 3 May 2021, at 20:36, Eli Schwartz wrote:
> 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)".

I don't think there's really any point writing MUST. The spec can recommend things, but no-one can force desktops to follow it if they don't think that behaviour provides the best experience. There's certainly a case for prompting the user to decide, but the place to make that case first is to the desktops which could actually implement it (assuming most users don't reach the generic fallback in xdg-open).

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

I suspect that adding pop-up dialogs to something that didn't previously use them is going to cause some issues. It also means that you would need another level of detection & fallback (zenity/kdialog, terminal prompts) inside what's already a fallback. And you probably still want an ultimate fallback where none of the GUI dialog tools are available and it's not running in a tty.

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

I may be wrong, but I'd guess that the mystery of xdg-open is more because it's a wrapper around a bunch of different desktop-specific tools with their own peculiarities. xdg-open could be effectively a different tool on my machine and yours, even if we have the same xdg-utils package from the same distro. Maybe it would have been better to implement xdg-open as a standalone tool rather than a wrapper around desktop tools, but I imagine that ship has long since sailed.

(And of course, there's nothing particularly wrong with people using other launcher tools if they want to - though I agree it's worth thinking about whether that points to problems with the default mechanisms.)

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20210504/d3d88b09/attachment.htm>