GNOME Bugzilla – Bug 610675
Register Tabs Do Not Display Since Nightly Build r18685
Last modified: 2018-06-29 22:35:24 UTC
The Windows nightly builds commencing with r18685 exhibit the following fault: The account name text that normally displays in the register tab is blank. The tabs "work", show a tooltip when the cursor hovers over the tab, and do allow an account to be selected - but there is no text or color highlighting displayed in the tab. This was previously working correctly in the latest 2.3.10 tagged build. I have rated this bug as major, as it will have a major impact on Windows users. The work around is to allow the cursor to hover on the tab, and wait a second or two for the tool tip to display which will correctly identify the tab.
From an update of SVN I see my patch has been backed out because of this problem. It seems strange that it was working at the 2.3.10 build but not now but still works OK on Linux. Do you know what changed on the windows front ?
(In reply to comment #1) > From an update of SVN I see my patch has been backed out because of this > problem. Right - sorry, I meant to report this in bug#608329 but forgot to do so yesterday. On windows we updated to more recent gtk versions, see packaging/win32/defaults.sh. The nightly build now uses gtk-2.18.7 but previous it was using 2.14.7. This most probably has caused this problem - maybe a change introduce in gtk-2.18? On Linux I don't see this problem, but I'm also using only gtk-2.16.1. I'd guess it appears on Linux once you're building with gtk-2.18 as well. Before committing the revert of r18714, I tried uncommenting the four calls to gtk_widget_modify_bg() and checked again, but the problem was still there. Hence, I guess the problem is that your helper function main_window_find_tab_event() might have failed with gtk-2.18, but I didn't see any console output and gnucash's trace file didn't show any gtk warnings as well.
For what it's worth, I have just upgraded my Linux Gentoo virtualbox guest to use gtk+-2.18.6 and glib-2.22.4. I then built GnuCash 2.3.10 build 18678 and this still works as expected, tab names and coloured tabs with no errors in trace file.
As another test, tried Gtk+2.18.7 and all works on Linux. Not sure how or if I can fix this.
I will try to get a windows development environment working so I can look at this from windows point of view.
Alternatively, I could try to run the windows version again with r18714 reverted and plenty of debugging output added. E.g. if the tab and eventbox hierarchy isn't structured in the way your code expected them to be. I'll report back if I get to this, but it might take until after the weekend.
Created attachment 154894 [details] [review] gnc-main-window.c file used for test. OK, I have used r18756 patched with enclosed patch which are the same changes originally made and compiled on Linux and Windows. Both show the tab names and highlight color so unless I am doing something different, I do not know what is going on.
Created attachment 155673 [details] [review] Reworked path for r18880 The patch in comment 7 doesn't apply to current trunk, because of the astyle indentation fixes. I have fixed the indentation so now it applies to r18880. I have not changed anything to the actual code, and I have no idea whether this patch fixes the problems this bug raises. I will apply the patch now, so we can see in the next nightly build whether the problem still remains.
I have installed r18883 and it looks like it fails still. This is strange as I built the same release in MSYS according to the wiki and it works. It also works on my Linux box. I thought I am using the correct package versions as I believe I downloaded them after the version updates above. To make sure, I have renamed my the build environment parent directory and I am in the process of creating a new build environment in case I am not using the correct versions as this will force all packages to be downloaded again but this will take some time. Could there be a difference between using a nightly build and just running it from "c:\soft\gnucash\inst\bin\gnucash.bat" as I have been doing ? I will report back later.
Bob, can you make sure that you start from at least r18884 for further debugging and patching ? You last patch had a bug that crashed GC for people that have changed the titles of the account tabs. This crash has been fixed in r18884. Thank you.
I have just completed the new build environment and as part svn it downloaded r18885. I have run this as above and the tab names are visible and the highlight colors are working. I will try and make a distribution executable as the wiki and then install that to see if there is a difference.
I have made a distribution executable from above and installed it on separate XP installation and the tabs fail. I am not sure what the difference is but will see if I can find out.
After some more investigations, I have found that I can get the tab names to work on a separate XP installation by doing the following. Install the release. Rename c:\program files\gnucash\bin\libgtk-win32-2.0-0.dll to *.dllx Copy the c:\soft\gnome\bin from the build environment to c:\gnome\bin on XP installation. Add c:\gnome\bin to the end of PATH in gnucash.cmd Run gnucash.cmd and all seems to work OK, tab names appear and also the color highlights. A strange thing is, if I copy the 147 files from gnome\bin and place them in gnucash\bin over writing any there already it fails again. Will try and identify what files in gnome\bin that are required.
OK I do not understand this..... The only file required is libgtk-win32-2.0-0.dll but it only works if it is not in gnucash\bin and gnucash\lib which are in the PATH, but put it in gnucash\lib\gnucash which is also in the PATH and it works.
(In reply to comment #14) > The only file required is libgtk-win32-2.0-0.dll but it only works if it is not > in gnucash\bin and gnucash\lib which are in the PATH, but put it in > gnucash\lib\gnucash which is also in the PATH and it works. Thanks for further investigating this! Indeed this sounds very weird. Maybe some initialization ordering issue? Maybe this is fixed by an older / newer version of libgtk-win32 DLL? I'm stll curious which of your code lines is triggering this error. As I wrote in comment#2, disabling your gtk_widget_modify_bg() call didn't have an influence here, so the account color itself doesn't seem to cause this. Now that you can reproduce this error, can you experiment with removing the tooltip part of your patch and see whether the problem disappears? The difficulty here is that your gnc-main-window patch contained several presumably independent features (coloring vs. tooltip vs. different widget stack), and I guess only one of those triggers this error. I suggest you should try to identify which of those parts is causing the problem.
OK I see it's been removed again, Oh well, any way I think I have found the problem. As far as I can tell, there is nothing wrong with the code but the problem seems to stem from me changing the widget order and mainly enabling the visibility of the event_box as this is where the color is changed. After a lot of compiling for little gain I think there are problems with the wimp engine. I must admit I have not herd of it but it is set in gtkrc as part of the Microsoft theme. If I disable it, the colors are OK but enabled and you get no text. I found this bug on bugzilla 598299 which I think is related and may affect other areas.
Created attachment 156295 [details] [review] Patch rebased to r18918 This patch is what has been backed out in r18918. It can be considered as a patch against the current trunk, if we are ready to reapply.
Yes, unfortunately we had to remove the patch for the 2.3.11 release. The list message today from David T. give me an interesting hint. Quoting: > I recently was able (through boatloads of help from John Ralls > and his jhbuild procedures--thank you, John!) to compile and > run 2.3.10 on Mac OS X. Upon firing it up, I noticed a small, > but annoying UI glitch: the main Accounts tab is now displaying > as "Ac..ts" I don't know for sure if this patch also causes the glitch on OS X, but it prompted me to open Preferences dialog -> Windows tab and play with the Tab width. Just by playing with this, the labels reappeared. But as soon as another window covered the tabs, the labels are gone again. So no real solution, but more hints to the cause.
*** Bug 613074 has been marked as a duplicate of this bug. ***
After poking at the behavior of r18678 (2.3.10) in OSX a bit more, I find that it forces ellipses on most, but not all, account labels. In one tree, I have the following tabs open, with their labels: Accounts Acc...nts Cash C...h PEQIX P...X CAIBX CA... SGOVX SGOVX Service Fees Servi... Fees Expenses Exp...ses Securities America Securities America I don't see any pattern here. The tab width is set to 25. The tab width adjustment *does* work, but only if the number is shorter than the width that the code is deciding to truncate. For the Securities America label, that value is 15. Make it 14, and that label becomes Securitie...America. The other, shorter, ones aren't affected until the value gets shorter than their length. As a first guess, it appears that the calculation of the rendered string length is wrong.
I left out of comment 20 that r18921 (SVN trunk HEAD when I tested it a couple of hours ago) doesn't exhibit the above behavior, so it very likely is caused by the changeset in question, which is why I marked 613074 as a duplicate of this bug.
Created attachment 156333 [details] [review] First part of patch to re-apply r18918, which already causes the bug Finally I've started to refactor the changes in gnc-main-window.c myself. The attached patch includes only the changes concerning the changed widget ordering, without the changes concerning color or tooltips. Current trunk (r18922) does not have this bug due to the revert in r18918. Current trunk plus the attached patch does have the bug again. So the patch and the widget ordering must be changed so that windows doesn't run into the bug. We can even start to add #ifdef G_OS_WIN32 here. By the way, I don't see the bug when starting gnucash from the "inst" or "build" tree, only when starting it from the "dist" directory which is also packaged in the installer. It is not necessary to install the installer - it is sufficient to run gnucash from the "dist/bin" directory. The reason is simple: Only in the "dist/bin" all the currently used libgtk DLLs are copied and will also be used. In contrast to this, in the inst or build directories, the libgtk/libglib etc. will be picked from the PATH, and as the dependency walker shows, apparently I have those DLLs in slightly different versions earlier in my path. This is probably the cause for Bob as well.
Comment on attachment 156333 [details] [review] First part of patch to re-apply r18918, which already causes the bug By the way I don't understand why the code (before or after this or Bob's patch) doesn't set a tab label using gtk_notebook_set_tab_label if we're retrieving it with gtk_notebood_get_tab_label afterwards.
I have been reading through bug #598299, which Bob dug up. The bug seems to suggest that gtk 2.18 for Windows is recommended (too buggy). Perhaps we should try to lower our gtk version back to 2.16 on Windows ?
(In reply to comment #23) > (From update of attachment 156333 [details] [review]) > By the way I don't understand why the code (before or after this or Bob's > patch) doesn't set a tab label using gtk_notebook_set_tab_label if we're > retrieving it with gtk_notebood_get_tab_label afterwards. The tab label is set via gtk_notebook_append_page_menu (in gnc_main_window_connect). I assume this function calls gtk_notebook_set_tab_label internally.
(In reply to comment #22) > sufficient to run gnucash from the "dist/bin" directory. The reason is simple: > Only in the "dist/bin" all the currently used libgtk DLLs are copied and will > also be used. In contrast to this, in the inst or build directories, the > libgtk/libglib etc. will be picked from the PATH, and as the dependency walker > shows, apparently I have those DLLs in slightly different versions earlier in > my path. This is probably the cause for Bob as well. Yes I noticed that but not knowing about the gtkrc file may be the cause. In the inst directories this file I do not think is picked up and so it works. If comment out the wimp engine, it also works but use loose the look and feel of Microsoft Windows so that was why I was thinking there was a problem with GTK+ wimp engine and hence the link.
(In reply to comment #22) > the widget ordering must be changed so that windows doesn't run into the bug. > We can even start to add #ifdef G_OS_WIN32 here. > I think I tried setting the event_box visibility to FALSE which allowed the labels to be seen as before but obviously no color, might be an option, not sure what you would do in the account.glade side to hide the color option if that was going to be a way forward, two glade files with the color option removed for windows ?
The code as it is now adds the tab label twice: The first time in gnc_main_window_open_page, line 2512: g_object_set_data(G_OBJECT (page), PLUGIN_PAGE_TAB_LABEL, label); This assigns the basic GtkLabel widget as the tab's label. The second time in gnc_main_window_connect, line 2329: gtk_notebook_append_page_menu (notebook, page->notebook_page, tab_hbox, menu_label); This time, the complete eventbox is set as the tab's label. I wonder if Windows Gtk takes issue with this double assignmend, but I can't test it myself. I can build on linux with the first entry (line 2512) commented out and all works fine. Perhaps it's worth trying on Windows as well ?
(In reply to comment #27) > > We can even start to add #ifdef G_OS_WIN32 here. > > I think I tried setting the event_box visibility to FALSE which allowed the > labels to be seen as before but obviously no color, might be an option, not > sure what you would do in the account.glade side to hide the color option IMHO it is tolerable to have that option in the Window version visible but without any visible effect. Hence, you would need to send us a patch for gnc-main-window.c with some #ifdef G_OS_WIN32 which means on Windows, the name is visible again, and on Linux, it additionally has color. The option without effect on windows is ok for now. We can guess it will be fixed in some future gtk version.
Created attachment 156555 [details] [review] New patch using ifdef G_OS_UNIX I have used the above patch as the basis for this one and added an ifdef G_OS_UNIX statement to set the visibility of the event_box TRUE for UNIX and any thing else will be FALSE. Compiled against r18929, on Linux I see the colored tabs and text. Compiled and run on XP, I see no color and the text as expected. For information, I did build r18885 with original patch with GTK+ 2.16.6 and this worked but any thing from 2.18.x fails. Looking in the source, they have effectively disabled the XP theme and so there may be reports of a change of look and feel for the release on XP machines.
Good point - we can even restrict the disabling of the event_box visibility to (pseudo-code) defined(G_OS_WIN32) && gtk_version == 2.18.x. I'll look into committing this patch tonight - thanks!
Comment on attachment 156555 [details] [review] New patch using ifdef G_OS_UNIX Committed but in parts: r18932, r18933, r18934. Thanks a lot!
Which, unfortunately, brings back the ellipses in OSX. It seems to be that the label character width is getting mangled somehow by putting the tab_hbox inside of the event_box instead of the other way around. I've opened 613375 to track it, since it isn't a Windows problem and anyway this one is closed.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=610675. Please update any external references or bookmarks.