Instead of using only hard-coded and varying defaults for Linux, MacOS and Windows, try to read the system's default command for "http" URI schemes and use it if found. If no usable default is available, fallback to the previous hard-coded defaults.
Besides being more user-friendly, this should solve issues on Windows where we always used "ShellExecute" and bypassed the configured browser command which led to errors on URLs with anchors (see #2405). You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2444
-- Commit Summary --
* Read default browser command using GIO
-- File Changes --
M src/keyfile.c (20)
-- Patch Links --
https://github.com/geany/geany/pull/2444.patch https://github.com/geany/geany/pull/2444.diff
While debugging #2405, I stumbled upon `g_app_info_get_default_for_uri_scheme` and noticed we can use it to query the default browser from the system and so do not need to use hard-coded defaults. Even though the hard-coded ones are still used if the GIO-based lookup fails.
I think this would be more user friendly than just having "firefox" or "open safari" which might not work for all users or might not what they have configured in their system.
For existing users, this change won't have any implications as it is used only for new configurations. For Linux and Mac(see below) users, there should be no degrade in functionality due to the fallback. For Windows users, we use the default browser command now and not the fixed `ShellExecute` variant any longer which was not configurable for users and is broken for URLs with anchors which we use in the preferences dialog. So Windows users will benefit most from this change.
There is a little chance of getting a bad or non-working default comand if the executable returned by `g_app_info_get_default_for_uri_scheme` does not work. I don't know if this can ever happen and if so, if it is worse than the previous behavior.
Things left to do: - test if this works at all on MacOS (@techee?) - test this on various Linux boxes (so far I tested it on ArchLinux+Xfce+Firefox) - test this on Windows
@eht16 pushed 1 commit.
3815e9aa6bd699e18b4aeae89640a7dee6d92f4c Unify opening URLs in browser on Windows
This seems like a good idea. :+1:
I've just tried it on macOS and: * g_app_info_get_executable () returns "Safari" (or "firefox" when the default browser is changed in the system settings) * g_app_info_get_commandline () returns NULL
But I think we'll still have to use the "open" command to launch the app returned by g_app_info_get_executable ().
OK, I didn't notice the launch commands in GAppInfo - and at least `g_app_info_launch_default_for_uri ()` does the right job and launches the correct browser just fine.
Tested on Windows and works as expected.
@techee the current code doesn't use the `g_app_info_launch*` functions but just uses Geany's spawn code as before on Linux and MacOS and now also for Windows. Does it work this way on MacOS as well, i.e. these changes as is?
Yeah, sure, with the current patch there's no change. I just thought you were planning to use the `g_app_info*` functions on unix platforms in the future.
I don't intend to replace our spawn API with the `g_app_info*` functions except the one in this patch. It seems the current code in Geany finally works well enough on all platforms :).
I noticed this does *not* work properly, at least on Windows, maybe also on other platforms. The returned command is not quoted, so if it contains spaces, this will break the usage in `utils_open_browser`.
We probably need to quote the command in order to be able to spawn it as command line (which we want in case the user wants to add command line parameters to the browser setting). I tried `g_shell_quote` but for whatever reasons, on Windows it uses single quotes and this does not work with our spawn implementation. `g_app_info_get_commandline` doesn't seem to work on MacOS.
I think I will give up on this here. If someone wants to continue, feel free.
github-comments@lists.geany.org