GNOME Bugzilla – Bug 732900
textview calls gtk_widget_set_allocation() on children out of ::size-allocate
Last modified: 2014-07-10 03:01:57 UTC
Textview used to have this old hack that would recursively translate and set the allocation on children widgets, (presumably for performance, although it's hard to speculate at this moment). This hack didn't turn out to be a problem until commit 4f89eb05c, that indirectly relies on the widget allocation not being manipulated externally, which brings the wrong clippings being applied to textview children (can be seen in the "multiple views" gtk demo) I'm attaching a patch to remove this hack and just replace it with gtk_widget_size_allocate(), it does seem to bring the expected behavior nowadays, and I can't think any reason it shouldn't.
Created attachment 280162 [details] [review] textview: Call gtk_widget_size_allocate() on children widgets invariably There was this hack, taken verbatim from GtkCList according to the comment, that would recursively translate the allocation during scrolling, and set it on children widgets through the direct gtk_widget_set_allocation() setter. Since commit 4f89eb05cf8a, this has caused the wrong clipping areas to children widgets of a textview. The reasons for this seem lost in time, and the approach seems indeed wrong for windowed widgets as the repositioning of those windows couldn't happen. So replace all of this with just a gtk_widget_size_allocate() call, which does work ok for the children widgets embedded in the "multiple views" gtk demo, and ought to work for every other widget.
Looks reasonable. I notice that attaching widgets to GTK_TEXT_WINDOW_WIDGET seems broken with or without this patch - the widget never shows up.
Attachment 280162 [details] pushed as 7178e34 - textview: Call gtk_widget_size_allocate() on children widgets invariably