New `MimeType` fields in .desktop

[Stefan Blachmann]

When I search the web, I find little information about this topic, so
I am not sure whether I understand you all correctly.
If anybody can give me a pointer where I can read about xdg-open
(documentation, specifications, etc), I'd be grateful.

Here my thoughts:
Shouldn't the DE, respective the file manager keep a LRU sorted list
of applications for each mime/file type, so that it sort of
"memorizes" and respect the users' favorite apps?
So the list of the applications shown on "Open With" should reflect
what the particular user *actually* prefers to use, and present this
topmost.

Some, like KDE, do not do this. So the user often has to go through
the app choosing menus each and every time (s)he wants to open a
particular file type.

This is very annoying.
But imho it's an implementation deficiency of the DE and not of the
specification.

Just to use the initial example of XCF files: if you want to just view
the file, using GIMP is overkill over using a simple viewer app.
So, the imho initial proposal would add a *lot* of complexity, only to
be overridden by the individual users' choice anyway.

However, for this to work, the particular DE/application chooser must
not be deficient, instead it must store the users' choices in its LRU
list for later invocations.

Imho xdg-open should just ask the interface script of the current DE
or application chooser for the preference-sorted app list for the
particular file/mime type, and use that list.
The DE/application chooser should remember the individual users'
choices, to respect these in subsequent invocations.

Again, I believe the problem is not the standard, but the laziness of
the DE/application choosers not to store/memorize the previous user
choices.

So I am not sure what to think about a real solution to that
long-standing issue.

Wouldn't it be a better solution to add a specification in XDG that
defines how to store individual users' application preference LRU
lists for each mime/file type, which thus can keep the individual
users' preferences, even when switching to another DE/application
chooser?


On 5/4/21, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> 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