GNOME Bugzilla – Bug 98207
gtk_widget_unparent doesn't correctly reset the widget state
Last modified: 2014-03-22 19:58:56 UTC
The attached testcase demonstrates how widgets aren't having their state reset when they are unparented. In the example program, move your mouse over the checkbutton, so that it has prelight. Then, press Alt-O, activating the Ok button, and the checkbutton will disappear. Press Alt-O another time, and the checkbutton will reappear (not underneath the mouse), but it will still have prelight drawn, as will the Ok button. The attached patch adds code to call gtk_widget_set_state (widget, GTK_STATE_NORMAL) on a widget and all of its children when it is unparented. This has no affect on a widget that becomes visible underneath the mouse pointer, etc.
Created attachment 12220 [details] testcase to demonstrate bug
Created attachment 12221 [details] [review] proposed fix
Adding the patch keyword.
Created attachment 12878 [details] Patch to the test case demonstrating other side of bug
But simply resetting the state doesn't really work either ... make the check button draw as a toggle button, and you'll see that your patch ends up rmeoving the "active" coloring from a pressed togglebutton when you remove it and add it back.
Thinking about it a bit, I think the right approach is: - When propagating state, keep track of whether the state of the widget is the result of set_state() on the widget itself or on a parent using a private GtkWidget flag - Consider GTK_WIDGET_STATE_NORMAL to be the "inherite from the parent" state. - When changing the hierarchy, use the private GtkWidget flag to properly update inherited states. - Make people who call gtk_widget_set_state(widget, foo) responsible for calling gtk_widget_set_state(widget, NORMAL) This sounds like quite a reasonable amount of work, and the severity of the bug is small, so I'm going to put on 2.2.1. Consider
Bug 93389 points out something of a problem with the above scheme; sometimes a parent widget will want to propagate different states to different children.
See also bug 109213 for a case where state should *not* propagate. Thinking through all of this is going to be a semi-major project so I'm going to put on the 2.4 milestone.
This has all changed considerably since 2003, I don't think keeping this bug open is useful.