When inside the "Einstellungen" (preferences) dialogue I click on "Hilfe" (help), no Helpwindows opens, instead I get the error message in the message pane:
14:21:42: Konnte URI "C:/Program Files (x86)/Geany/share/doc/geany/html/index.html#general-startup-preferences" nicht öffnen: Das System kann die angegebene Datei nicht finden.
I don't understand, why this error message pops up, because using Windows Explorer, I can locate the index.html under exactly this path.
My guess is that this is related to the weird Windows naming conventions, where several alias names are used for the same folder, depending on the locale of the Windows installation. So, while Windows Explorer can find the html directory when pasting the string
_C:\Program Files (x86)\Geany\share\doc\geany\html_
into the Windows explorer bar, the left side pane (which shows the directory tree) displays the top-level directory not as "Program Files (x86)", but as "Programme (x86)", so perhaps the correct path to be used should be
_C:\Programme (x86)\Geany\share\doc\geany\html_
This is a recorded message, please always provide the version of Geany, Glib and GTK (see lines near the top of Help->Debug Messages) and the operating system and version you are using.
OMG!! Locale specific file paths, MS what were you thinking!!!!
I guess the Geany windows download is created on an English locale so the path recorded is `...Program Files...`. Not sure thats fixable since the path is hard coded in the Geany executable, @eht16 ?
I believe this is a duplicate of #1522.
OMG!! Locale specific file paths, MS what were you thinking!!!!
I couldn't agree enough with that.
Even though my current guess for the problem here might be just the anchor in the link.
@rovf does the main help work when clicking the Help->Help menu item? For me, the main help works but not the anchor links. The exactly same code is used to construct the URLs and to open the browser.
https://stackoverflow.com/questions/26305322/shellexecute-fails-for-local-ht... pretty much describes our problem: `ShellExecute(..., "open", ...)` does not handle URL anchors properly.
I just tested dropping the Windows specific code for opening a browser and just used the non-Windows code and it's working perfectly fine for all cases I tested (Pref dialog links, About dialog link, Help menu item links, Build->Run command with "builtin") and all worked. So I'm wondering to just use the non-Windows code. The only "problem" is the browser default. We set it to "firefox" which usually works on Linux but not on Windows (except the user adds firefox.exe to $PATH). Fortunately, we can read the system default browser with GIO: ```c GAppInfo *ai1 = g_app_info_get_default_for_uri_scheme("http"); g_app_info_get_commandline(ai1) ``` this worked on my Windows box and the returned command could be opened as is.
So, a possible solution could be to drop the Windows specific code for opening the browser and use GIO to try to read the default browser if it is not set (and leave it unset if unset).
@rovf does the main help work when clicking the Help->Help menu item?
Exactly. The main help (bound to F1) works.
In windows, when you enter a filename like "file.html" at the command prompt or through a system call, the file extension is used to determine the default file handler. Just as "file.xls" will start excel, "file.html" will start the default browser. However trying to open "file.html#anchor" will not work, since that is not a windows filename.
If you use the the browser configured in the Edit -> Preferences ->Tools Browser setting should work with both a bare URL and a URL including an anchor. It may be necessary to use the -url option, although it sounds like using it is optional.
Maybe we should drop the windows specific open browser code and just run the configured app.
But the problem with that is its default of firefox is not installed by default on most windows systems, I guess thats why the windows code using shell open was added to try to find the system browser.
This [comment](https://github.com/geany/geany/issues/2405#issuecomment-559265994) seems to describe a simplification of the code that works for both windows, mac and Linux.
@djhenderson no it still needs specific code for windows unless @eht16 is suggesting throwing the browser setting away and using the app info for all platforms?
Maybe use the setting if set, else the appinfo, and make the default setting empty, would be a better approach for all platforms (if it works on Macos @techee)? That way it should open help in chrome for me, not Friedfox, yay can uninstall it and not update it.
Also it needs a fairly new glib to be able to start edge (the win10 default browser), see [here](https://gitlab.gnome.org/GNOME/glib/-/commit/0c85348efcb2877ab56d1ee79f7379b...) but maybe msys2 has that?
On msys2/mingw64, we have mingw-w64-x86_64-glib2 2.68.4-1, which appears to be what geany 1.38beta1 is built with.
Glib GLib 2.69.3 appears to be the latest stable release on [https://gitlab.gnome.org/GNOME/glib%5D(https://gitlab.gnome.org/GNOME/glib)
Ok, and since @eht16 controls the version in Windows its ok, just need to know it works on the other platforms as well, on oldish Linux and Macos.
@djhenderson no it still needs specific code for windows unless @eht16 is suggesting throwing the browser setting away and using the app info for all platforms?
He is! The #2444 does exactly that.
Maybe use the setting if set, else the appinfo, and make the default setting empty, would be a better approach for all platforms (if it works on Macos @techee)? That way it should open help in chrome for me, not Friedfox, yay can uninstall it and not update it.
The idea of the implementation in #2444 is rather to set the initial value of the setting with the appinfo browser and then use the setting.
Anyway, #2444 doesn't work properly on Windows, see https://github.com/geany/geany/pull/2444#issuecomment-918601467. Not sure why I noticed this earlier :(.
The idea of the implementation in #2444 is rather to set the initial value of the setting with the appinfo browser and then use the setting.
That would mean that the user can't select the browser, thats why I did it the other way around.
Anyway, #2444 doesn't work properly on Windows, see #2444 (comment). Not sure why I noticed this earlier :(.
Oh well, makes the above point moot then.
github-comments@lists.geany.org