After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 457213 - Resizing SLR window causes it to show up as blank next time
Resizing SLR window causes it to show up as blank next time
Status: VERIFIED FIXED
Product: GnuCash
Classification: Other
Component: Windows
2.2.x
Other All
: Normal minor
: ---
Assigned To: Andreas Köhler
Christian Stimming
Depends on:
Blocks:
 
 
Reported: 2007-07-15 21:47 UTC by Zach Sadecki
Modified: 2018-06-29 21:42 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
screenshot (12.32 KB, image/png)
2007-07-16 04:01 UTC, Zach Sadecki 		Details

Description Zach Sadecki 2007-07-15 21:47:25 UTC 
Please describe the problem:
Open the Since Last Run... dialog, then resize the window, then close it.  Open it again and the window will be blank.  Grab it to resize, and as soon as it changes size the contents will then appear.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Josh Sled 2007-07-16 03:51:54 UTC 
I can't reprodce on 'nix.  In what way do you close the SLR dialog?  Cancel?  Window manager close?  Does it matter?
Comment 2 Zach Sadecki 2007-07-16 03:59:32 UTC 
I close it using the window manager close.  There is a possibility that it's releated to bug 432021, but it happens using both the wimp and default gnome theme (which isn't affected by that other bug.)

Also if I just grab the window and move it, it immediately redraws and appears correct.
Comment 3 Zach Sadecki 2007-07-16 04:01:36 UTC 
Created attachment 91842 [details]
screenshot

A screenshot of the bad window.  It was stretched to be taller, but as you can see the buttons look like they're about where they'd be for the default size... and all the SX text is missing.
Comment 4 Josh Sled 2007-07-16 13:51:37 UTC 
That's strange ... that's just the standard GtkTreeView, as well, that's not painting.  I somehow doubt it's a general problem, but instead something about how we're using it.  I wonder if any of the windows users have GtkTreeView problems more widely?

(Also, I note that the layout for the button dialog controls is less than ideal. :( )
Comment 5 Andreas Köhler 2007-07-16 20:32:58 UTC 
We had a similar bug a while ago which was fixed in GLib.
Time to produce a minimal test case.
Confirming.
Comment 6 Andreas Köhler 2007-07-16 21:10:29 UTC 
(In reply to comment #5)
> We had a similar bug a while ago which was fixed in GLib.
I meant Gtk+.

Zach, may you please extract ftp://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.10/gtk+-2.10.13.zip
(or 2.10.11, which we are using currently) into the gnucash folder?  It seems to me that 2.10.12 or 13 fixed this issue, but I am not sure.
Comment 7 Zach Sadecki 2007-07-17 00:35:42 UTC 
It works fine after extracting 2.10.13 into the gnucash folder...
Comment 8 Andreas Köhler 2007-08-07 07:59:52 UTC 
2.2.1 will be built with Gtk+ 2.10.13 or higher.
Closing.
Comment 9 John Ralls 2018-06-29 21:42:55 UTC 
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=457213. Please update any external references or bookmarks.