Sensitivity changes were not properly propagated down the
hierarchy. There were two issues here:
a) correctly identifying when a state change request affects
sensitivity
b) not filtering out sensitivity in gtk_widget_propagate_state(),
since gtk_widget_set_sensitivity() uses that to do its work
https://bugzilla.gnome.org/show_bug.cgi?id=641431
Optimized GtkSizeGroup code that is invoked for every queued resize
and every request that is not previously cached by trading qdata on
widgets for 3 extra bitfields on the GtkWidgetPrivate structure.
so pull the SELECTED state flag out of the !sensitive branch. Also,
don't make FOCUSED depend on SELECTED here, it's up to the widget to
decide whether or not that is possible.
It is used to get the default providers, without them
the style context can't do much. A check for NULL screen
is done before any sensitive call to
gtk_style_context_set_screen(), in the hope that any widget
will open the display before doing anything related to
styling. Fixes bug #641429, reported by Bastien Nocera.
Before this patch, unsetting the filter manually before disposing
the recent chooser menu (or unsetting the filter twice), would cause
warnings (or invalid memory accesses).
Having default implementations on abstract classes that do nothing
or print errors make life easier for language bindings implementors,
inside GTK+ this makes little or no difference.
Having default implementations on abstract classes that do nothing
or print errors make life easier for language bindings implementors,
inside GTK+ this makes little or no difference.
constructors which take an object of the same class as its first argument are
mis-detected as method call with "self" argument by the GIR scanner. Using the
new (constructor) annotation from bug 561264, mark some of them as proper
constuctors, so that you can call them with NULL as first argument from
bindings; in particular, this fixes gdk_window_new() and the
gtk_radio_button_new_with*() constructors.
b3f6f67c changed the loop from while() to for() in gtk_fixed_forall(),
but that's wrong since the callback can have side-effects on the list,
in case the current child gets removed. And that's the case when the
widget is destroyed.
Patch by Vincent Untz
https://bugzilla.gnome.org/show_bug.cgi?id=641196
The previous function gdk_drag_get_protocol_for_display() took native
window handles, so it had to be changed. Because it didn't do what it
was named to do (it didn't return a protocol even though it was named
get_protocol) and because it doesn't operate on the display anymore but
on the actual window, it's now called gdk_window_get_drag_protocol().
It turns out that the gtk_grab_remove() can trigger a do_prelight()
call, which may end up changing prelight_node, and then the state
gets messed up. Moving the grab removal until after we're done with
button_pressed_node and prlight_node makes expanders work reliably.
One thing that is still not right is that the expander doesn't get
prelight again after the animation is done, if you manage to release
without any additional motion events.
https://bugzilla.gnome.org/show_bug.cgi?id=641039
