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.
Instead rely on state_flags & GTK_STATE_FLAG_INSENSITIVE to tell us if a
widget is sensitive.
This has the huge benefit that the way the widget is actually rendered
corresponds to the return value of gtk_widget_is_sensitive().
As a side effect, we do not ever allow unsetting the
GTK_STATE_FLAG_INSENSITIVE for a widget the is set to not be sensitive
(via gtk_widget_set_sensitive()). This way we stop propagation of making
stuff sensitive at insensitive widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=642918
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.
This commit makes GTK_ALIGN_START/_END pay attention to
the text direction when used in horizontal context.
This is how similar parameters in GtkMisc and GtkAlignment work,
and is generally expected of GTK+ positioning parameters. And this
is new GTK+ 3 api, so it is basically still unused at this point.
If explicit right/left turn out to be needed at some point, we
can expand the enumeration with new values.
Use the _NET_SYSTEM_TRAY_ICON_SIZE property set by the tray mananger as
a hint that we should use a specific icon size. This allows the tray to
instruct us that it expects 16x16 icons, for example.
Bug #645232
Async callbacks are delivered in idles, so we need to make sure
we get the gdk lock before calling any gdk/gtk stuff. This was
missing in a few places.
(cherry picked from commit e274dbbdce)
This ensures that widgets that aren't ported and rely on the style-set
signal being emitted work as well as before. They should not rely on
style-set being emitted however.
Note that this function is a no-op if the initial style has been set
already and is very cheap if it has not been set yet. It only becomes
relevant if the resulting style actually gets used.
https://bugzilla.gnome.org/show_bug.cgi?id=639584
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.
Now that we have wesome macros in glib 2.0, we can use them. Woohoo, GTK
2.0 will be so awesome in the future.
(Did anybody touch dnd code this millenium?)
