After David Cousens reported in https://lists.gnucash.org/pipermail/gnucash-devel/2018-September/042618.html, I run a test and it seems the context sensitive help were broken, while switching from GTK2 to GTK3. I am pretty sure, when I last run 2.6.21, and pressed the help button, I got the right page presented by yelp. Now the starting symbol appears and disappears after some time again - this means usually a crash of yelp. While not in any dialog pressing [F1] or menu Help->Content results in yelp displaying the Help Content.
Edit->Preferences was the page, I opened before pressed [Help].
In Windows the help button on Preferences just opens the Help Browser at the title page of GnuCash help. It works correctly on MacOS, opening file:///Applications/Gnucash.app/Contents/Resources/en.lproj/GnuCash%20Help/set-prefs.html in the default browser, but MacOS has custom code for that.
Hmm, Windows has it's own code too. The function in question is gnc_gnome_help in gnucash/gnome-utils/gnc-gnome-utils.c. A little more testing in Debian 9: If I first start Yelp with Help>Contents and then click the Help button in the Preferences dialog Yelp switches to the correct page, even if I've closed Yelp. If I open Yelp with Help>Concepts Guide and click the Help button in Preferences with Yelp still open Yelp immediately crashes unless I left the Contents instance open when I launched the Guide instance. `ps -a` shows only one each of yelp, WebKitNetworkPr, and WebKitWebProcess running and all three disappear when Yelp crashes. It looks to me like a Yelp bug, possibly related to https://gitlab.gnome.org/GNOME/yelp/issues/116 https://gitlab.gnome.org/GNOME/yelp/issues/121 (which look to me like duplicates). The only difference between them and our problem is that our URL uses '?' instead of '#'.
The Windows failure is fixed by my fix of bug 796800, leaving only the Yelp bug. ISTM this is now "not GnuCash".
original problem: Build from Gnucash master after the merge branch maint at 7/9/2018 on Linux Mint 19 - Tara The behavior is however a bit strange. If I restart GnuCash then do Business->Vendor->New Bill then click the Help on the dialog, no help Window opens. If I then close the dialog and open the Help->Contents to display the help window, leaving it open, then go through the sequence Business->Vendor->New Bill and click the help button again the information on Invoices is displayed in the open help window. Close the help window then press the Help button on the dialog again and nothing happens again. I get the same behavior with the Help from the menu in the Reconcile window and the New Invoice, Close Book dialog etc. It appears that there has to be a help window already open and then the context snesitive page can be displayed in that window, but the Help button in the dialog cannot initiate opening the Help Window on its own. This may be the designed behavvior and if so it just needs to be documented but it would be nice to have context help come up whether you have a help window open or not. I don't normally notice it because I usually use the online Help and Tutorial.. in a browser window.
It seems to become more worse. While with a released 3.2 the workaround (open help; open dialog; get context sensitive help) worked, with Build ID: git 3.2-270-g5609b704c+ (2018-09-14) the already open help window disappears as soon as I click the Help Button in the dialog. After calling help "Recursion depth exceeded calculating fg color" or "Recursion depth exceeded calculating bg color" appeared each 16 times before and also after the crash on the console. yelp 3.28.1
Well, it doesn't do any good to diesct it here. Either comment on one of the issues I reffed in comment 3 or raise bugs with your distros. As you know you'll get more attention if you can provide a stack trace of the crash. That should be easy now that it crashes an already-running Yelp instance.
John, it was more or less a note to myself while testing on Bug 795425.
The yelp bug says, it works without anchor. Can we split gnc-gnome.util.c:15 in 2 calls: 1. uri without anchor success = gtk_show_uri_on_window (NULL, uri, gtk_get_current_event_time (), &error); 2. update the window to select the anchor?
> Can we split gnc-gnome.util.c:15 in 2 calls: > 1. uri without anchor > success = gtk_show_uri_on_window (NULL, uri, gtk_get_current_event_time (), &error); > 2. update the window to select the anchor? No, because gtk_show_uri_on_window() opens the URI in the default application for the URI's mime type so there's no way to send the anchor.
I have tried several tricks, but none of them was successful. In theory I should close it as NOTGNUCASH, but I wish to keep it open as reminder.
*** Bug 128772 has been marked as a duplicate of this bug. ***
