Bug#172436: Updated BROWSER proposal
On Sun, 21 Jul 2019 at 21:08:15 -0700, Russ Allbery wrote:
> I think it's clear that we're not making forward progress here, and the
> lack of a clear specification for the BROWSER environment variable doesn't
> seem to be causing a lot of noticable ongoing pain. I'm therefore going
> to close this bug as something on which we've just not reached consensus.
As a note for anyone who comes back to this, before the bug gets archived:
freedesktop.org has developed a system of URI-scheme handlers since this
bug was opened, which as far as I know is used in all the major desktop
environments (this is definitely the case for GNOME and the various forks
based on older GNOME releases, and I'm fairly sure it's also true for KDE,
XFCE, LXDE). In that system, the equivalent of Debian's x-www-browser
alternative is to register a MIME type handler for the pseudo-MIME-types
"x-scheme-handler/http" and "x-scheme-handler/https". A similar approach
works for other URI schemes, for example "x-scheme-handler/mailto".
Desktop-oriented libraries should already have a way to launch the default
handler for a URI, for example g_app_info_launch_default_for_uri_async()
in GLib or bool QDesktopServices::openUrl(const QUrl&) in Qt. This is
often a better choice than running a subprocess.
Applications that specifically want a command-line/subprocess-based
interface can launch a URI in a browser with something like:
- xdg-open http://example.com (xdg-utils)
- a 1000+-line shell script with many special cases; uses $BROWSER when
not in an X11 environment
- gio open http://example.com (libglib2.0-bin)
- CLI wrapper for g_app_info_launch_default_for_uri_async()
- requires GLib, but in practice all mainstream desktop environments
are going to have that anyway, e.g. via Firefox or Qt; does not attempt
to handle the non-graphical case
Regards,
smcv
Reply to: