GNOME Bugzilla – Bug 125597
GtkTextView in GtkScrolledWindow not redraw properly
Last modified: 2007-07-08 22:28:00 UTC
I have a GtkTextView inside a GtkScrolledWindow (with automatic scrollbars both horizontally and vertically), which in turn is packed into the bottom half of a GtkVPaned widget. (If it matters, there is a DrawingArea in the top half of the VPaned). When I drag the VPaned separator upwards (i.e. make the text view larger), everything is okay. When I drag the separator downwards (i.e. make the text view smaller), the text view doesn't redraw correctly. Instead, it leaves multiple copies of the separator in the text view window, corrupting the text. It appears as though the separator is sometimes drawn in the new position, and then the contents of the text view are moved downwards, including the separator. This seems to happen regardless of the amount of text in the window, i.e. it's independent of whether there is a vertical scrollbar or not. This works okay when the same program is run under Linux. I'm using the V2.2.4 version of GTK for Windows, as downloaded from Tor's website on 1st September 2003. Apologies if this is a duplicate, but I tried searching for similar bugs and couldn't find any.
Created attachment 20974 [details] Example screenshot of a corrupted window.
This could be related to the fact that X11 GraphicsExposes aren't properly emulated by gdk/win32?
I don't think so, since GCs are created with GraphicsExpose OFF. The only places they're turned on explicitly are: $ grep _set_expos *.c gtkclist.c: gdk_gc_set_exposures (clist->fg_gc, TRUE); gtkruler.c: gdk_gc_set_exposures (ruler->non_gr_exp_gc, FALSE); gtktext.c: gdk_gc_set_exposures (text->gc, TRUE); <-- *** Is the widget in the screenshot GtkText? It might be time to use GtkTextView! However, I see a similar problem with xchat/win32 using a GtkVPaned with GtkTreeView not redrawing itself properly (however that's gtk 2.2.4). P.S. Tor, you actually wrote some code to implement GraphicsExpose on win32, but it never got commited. It's probably in the mailing-list archives somewhere.
No, it's definitely already a GtkTextView, not a GtkText. By the way, this still happens with the latest version of GTK+ that I downloaded from Tor's website on the 21st June (which I believe is V2.4.3).
I think this is related to bug #144269 and it is present in the current CVS sources. My theory is it's caused by the window repositioning / resizing code in gdkgeometry-win32.c but I don't have a fix for it. The workaround is to queue a redraw when the allocation changes.
*** This bug has been marked as a duplicate of 144269 ***