The intention of this patch is to make the code clearer, shorter and
most of all to avoid recreating the widget path and setting it path
twice on the style context when the style context was recreated.
This patch optimizes window resizes by assuming that if a widget
has the same height at a width of 50 as with a width of 150, the
height for width 100 will also be the same.
The patch also further optimizes the cache allocator, now there
are 2 pointer arrays of up to a maximum of 5 requests, the arrays
will only be allocated if a request is ever made in that orientation
and the array will be sparse until each request is made (i.e. if a
label can only wrap to 3 lines, there will only be 3 out of a
possible 5 SizeRequest structures allocated to cache it).
This patch makes contextual height-for-width request caching
optional (the contextual cache is not allocated for widgets that
report GTK_SIZE_REQUEST_CONSTANT_SIZE).
The constant size request mode defines a request mode where
height-for-width geometry is unneeded, thus optimizing GTK+
by reducing the overall amount of requests that need to be
performed and cached while resizing an interface.
Fixes Bug 639584 - initial emission of GtkWidget:style-set is
not happening.
GtkWidget was filtering out ::style-updated (and ::style-set)
emissions until the widget was realized in order to avoid often
useless updates during widget construction and placing.
This is now done instead until the widget has a parent/screen,
which ensures the initial emission happen prior to the first
size negociation, while still filtering out all early emissions
during construction.
Writing onto the passed-in GtkStateData could cause changes that would
propagate to siblings, as the data was not reset again.
By copying the data structure, this is avoided and the proper values are
passed to sibling widgets.
GtkWidget now parses custom attributes like
<style>
<class name="dark-label"/>
<class name="big-heading"/>
</style>
to add style classes to widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=643347
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.
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.
This management is better done per-widget rather than per-screen,
as windows being destroyed won't trigger a leave notify for the
devices on top of it, and this information is too transitive
to keep weak refs and such.
This fixes the critical warning seen in gtk/tests/testing.
Instead of checking if klass->get_request_mode is != NULL from
the gtk_widget_get_request_mode() api, this allows classes to
trust that there is a default implementation and chain up (specifically
added this for gtkmm wrapper objects).
GtkStateType was generally used as an index in GtkStyle color arrays, so
bigger values will cause invalid memory accesses in widgets that are still
doing that. this was seen in focused GtkIconViews for example
together with commit 8903615a34, this finally fixes bug #640282.
Insensitivity is handled separatedly in _gtk_widget_update_state_flags(),
but the insensitive flag is mistakenly unset afterwards if clear is TRUE
in gtk_widget_set_state_flags().
There is only one widget supposed to have the focused flag at a given time,
so avoid propagating the state down the hierarchy, the focused flag is now
also set in _gtk_widget_set_has_focus().
