New `MimeType` fields in .desktop

[Stefan Blachmann]

I have looked at the xdg-open script.

I'd like best if I could just set an environment variable XDG_OPEN to
another program.
So xdg-open just passes through to my script.

I ask because, instead of using xdg-open, I would like to use my
personal app chooser for my Meow&Purr menu+filebrowser for FVWM.
Meow&Purr keeps LRU lists for the preferred apps for every and each
mime/file type.
So the default app is the last-used for any particular file type, and
the most-recently used apps for that file type are always at top in
the OpenWith list.
This solution imho best adapts to the users' personal preferences.

Because, who doesn't hate the bad UX when, for example xdg-open thinks
GIMP is the right app to view a PDF file :)

So I kindly ask, could there be added such an environment variable
XDG_OPEN specifying an alternative handler, to allow non-mainstream
DE/WMs handle the open dialog themselves?


On 5/4/21, Stefan Blachmann <sblachmann at gmail.com> wrote:
> 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
>