With regard to all of your questions:

In general the DE specific opener command is preferred as it will do DE specific things such as e.g. record opened files in "recently opened" lists and whatnot. xdg-open will proxy out to those commands by doing DE detection, so there's no reason to even consider various*-open programs other than xdg-open except if you don't trust xdg-open to perform said browser detection (or from within a DE-specific component calling out to other parts of said DE).

gio launch and gtk-launch won't exist on all systems. In particular, systems without gnome installed. Such as KDE. What's the story for supporting KDE?

gtk-launch will be called "gtk4-launch" on various gnome systems depending on whether one has gtk 3 or 4.

The best way to handle this is actually just to go ahead and implement the Desktop File Specification and parse the Exec= line yourself then directly execute the relevant command.

I will say that I've essentially never actually wanted a module to open a local filesystem file in a web browser. I've wanted a module to open a local filesystem file in "the default application handler, like xdg-open but portable to non Linux operating systems" all the time though.

Unsure what, if anything, you should derive from that.

gio launch and gtk-launch won't exist on all systems.

Yeah, that's handled by the detections already in place. The goal here is to use "launch app by name" where available, which is why it's currently purely additive to what's there already.

Ifxdg-open supported passing an app for a standard 'open with ...', that would be awesome and the simpler way to go. Apparently someone madexdg-launch, which seems to be exactly this. I wishxdg-open had this, andreally hope I'm just missing it somewhere and someone can point me to the xdg command to launch an app by name (or default mime-type) with a URL.

What's the story for supporting KDE?

I'm not very familiar with KDE, butlooking at docs, I think this should be:

kfmclient exec URL BROWSER_NAME

but it's unclear from the docs if the current defaultkfmclient openURL behavior opens in the default browser or default app. If anyone knows the way to spell "open $url with $app" for KDE, I'll add it.

The best way to handle this is actually just to go ahead and implement the Desktop File Specification and parse the Exec= line yourself then directly execute the relevant command.

Would folks prefer that? It is simpler, in a way.

I've wanted a module to open a local filesystem file in "the default application handler, like xdg-open but portable to non Linux operating systems" all the time though.

Yeah, that makes sense as a feature request, and is already at#47427 (opened 17 years ago). But it isn't what thewebbrowser module claims to do, so doesn't seem actionable here.

I'm not very familiar with KDE, butlooking at docs, I think this should be:

kfmclient exec URL BROWSER_NAME

but it's unclear from the docs if the current defaultkfmclient openURL behavior opens in the default browser or default app. If anyone knows the way to spell "open $url with $app" for KDE, I'll add it.

kfmclient is part of the konqueror package and openURL opens the url in Konqueror (a somewhat popular browser in the KDE world). It is no different from hardcoding firefox.

kfmclient exec pops up an empty (unpopulated) dialog asking you to choose an application. Maybe I'm misusing it, since KDE isn't my primary desktop. The box at the top does allow you to type in the name of a program executable to launch with. It's not remembering anything for me either. Note "remember application association" indicates it's in theory supposed to be offering xdg-open compatiblemimetype options for "inode/directory" or "text/html"

kfmclient exec file:///tmp

kfmclient exec https://example.com

Note also that xdg-open internally uses kde-open "for recognized versions of KDE" and the fallback for really old KDE versions is...kfmclient exec, in remembrance of the fact that in the long ago, konqueror was available in all KDE sessions.

Yeah, that makes sense as a feature request, and is already at#47427 (opened 17 years ago). But it isn't what thewebbrowser module claims to do, so doesn't seem actionable here.

Yeah I know. The point was rather that if I were the one designing a "webbrowser" module from scratch I would simply reject any urls that didn't have a protocol which targets the World Wide Web. :P

I'm biased though.

kfmclient exec file:///tmp

Yeah, I don't think we should add any calls tokfmclient exec URL, since that aims to do the same default-opener action asxdg-open. I would only use it in the form that allows specifyingexplicitly to launch in a browser.

I just did a fresh install of kubuntu 24.04, and observed:

1. kfmclient is not available, the current implementation is apparentlykioclient
2. kioclient exec file://url without specifying what to launch definitely isn't what we want, as you demonstrated
3. the what-to-launch apparently wants a url scheme, not an app name, so the right command iskioclient exec file://$PWD/file.html x-scheme-handler/https (i.e. open url X with default handler for mime Y). Advantage: we don't need to lookup the browser name for this to work.
4. gtk-launchis present andgtk-launch $(xdg-settings get default-web-browser) file://$PWD/file.html does the right thing, so the desired behavior does happen by default with this PR as-is (forkubuntu, at least). I don't know how common that will be.

Rekioclient --commands output:

 kioclient exec 'url' ['mimetype']            # Tries to open the document pointed to by 'url', in the application            # associated with it in KDE. You may omit 'mimetype'.            # In that case the mimetype is determined automatically.            # 'url' can be the URL of a document, a *.desktop file,            # or an executable.

I've addedkioclient exec {url} x-scheme-handler/https on KDE and support for the gtk4-launch name.

gtk-launch will be available only if the user happens to have gtk 3.x apps installed. Many users of KDE desktops only have Qt apps installed.

gtk4-launch is similar but for gtk 4.x

You need to check both and you cannot assume either one.

Users using Qt-based window managers or EFL or various minimalist ones in combination with their favorite set of Qt apps but who don't have the KDE Framework installed. xdg-open will still work and still exist albeit it will open https urls in the default webbrowser while violating the webbrowser.open module docs for files, because people mostly assume xdg-utils is all that needs to be portable and broadly available.

You need a fallback for those people and I don't think you will get one unless you implement the Desktop File specification yourself and read theini files directly.

You need to check both and you cannot assume either one.

Yup, that's done here.

You need a fallback for those people

To be clear, the changes here are (almost) purely in addition to what's already there, which is a pretty long try sequence, so all the fallbacks that already exist for that case remain present. I've only added a couple and removed none, soxdg-open remains the top priority ifgtk[4]-launch is not found. The only change that's not purely an addition is skippingxdg-open (and a couple similar entries) forfile:// URLs, at which point it proceeds through the fairly lengthy fallback chain of about 15 browsers by name.

Andall of these remain lower priority than the longstanding behavior of launching the default browser directlyif it's found by name (e.g. if default browser isfirefox.desktop andfirefox is on $PATH). That's all unchanged by this PR.