GNOME Bugzilla – Bug 135903
GtkDialog doesn't redraw area after resizable is set
Last modified: 2005-06-21 13:34:20 UTC
If I change a dialog from not resizable to resizable, any widgets that are now drawn where the old window was are not drawn correctly. Two screenshots are attached to clarify the issue. One is of the bug, the other is the bug superimposed with the 'before shot' at a low alpha.
Created attachment 25008 [details] sshot showing bug
Created attachment 25009 [details] Superimposed shot of before and after
There are a few more comments on this at: http://bugzilla.gnome.org/show_bug.cgi?id=135902
The situation is: - w is not visible and its position is outside its parents allocation. - someone calls gtk_widget_show(w), which queues a resize on w and it parent. Also w's position is invalidated - gdk_window_process_updates() is called, but w is not drawn at this point because it is outside its parent's allocation - w is size allocated, but doesn't change size or is !redraw_on_allocate, so isn't invalidated A similar argument applies to children of w. So, it seems we will need a flag or something to indicate that the next size allocate is the first one after map and so _has_ to invalidate the widget, no matter what the widget itself thinks. Also, it seems that the queue_resize() done by gtk_widget_show() should actually be a "deep" resize so that all the children will also be size allocated.
A private GTK_REPAINT_NEEDED flag sounds approximately right; another possibility would be to set a widgets allocation back to -1-1x1x1 on unmapping it, but that has at least the potential to be less efficient / more side-effect causing.
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
*** Bug 155190 has been marked as a duplicate of this bug. ***
Created attachment 36452 [details] Testcase in C
Created attachment 36453 [details] [review] Patch This patch fixes the problem with introducing new private flag ALLOC_INVALID which shows that allocation structure is not valid anymore. This flag is set in gtk_widget_real_hide and unset in gtk_widget_size_allocate and forces widget redraw.
Also, note that bug 135502 describes workaround this problem in GtkFileChooserDefault. Probably, it this workaround should be removed when this bug will be fixed.
Created attachment 36454 [details] [review] Patch Sorry, the bug about filechooser was 135902. And here is updated patch.
Hmm, I'm not seeing the problem with either your testcase or the filechooser after removing the workaround on cvs HEAD. I do see it on 2.6. So maybe the cairo changes have fixed this somehow ?
This happens to be fixed by the draw-border changes in cvs HEAD, so I'm just going to remove the workaround in gtkfilechooserdefault.c
Just to explain why briefly - the reason is that now gtk_widget_queue_draw() on a widget draws the bounding box of the widget and all (mapped) children rather than just the bounding box of the widget. So, this means that queue_draw() works properly in the intermediate state where we've mapped the child, but not yet reallocated the parent.
*** Bug 155526 has been marked as a duplicate of this bug. ***