Themes may want to render handles differently depending on whether
the widget is in selection mode (2 handles enclosing a selection) or
cursor mode (one handle pointing out the insertion cursor).
This improves both interaction and theming, as it allows
arbitrary handle shapes while just being draggable from
the visible areas.
This way themes can set up handles with the hotspot visually
displaced from the horizontal center, as long as the hotspot
lies centered in the image/svg asset.
The check on the handle to be drawn on the mask was based on the yet to
be set priv->windows pointers, pass explicitly the handle position to
have the shape correctly initialized on non-composited environments
The GtkNotebook drag-motion event handler may install a timeout when
hovering over a tab, in order to switch to it.
On the other hand it's desirable for applications to use the empty tab
area as a drop target, so the drag-motion handler returns FALSE
(also in case it installs the switch tab timeout), as explained in
https://bugzilla.gnome.org/show_bug.cgi?id=350665.
Unfortunately, applications can use the tab label widget (or a child
of it) as a different drop target area, and install their own
drag-motion handler there.
In this scenario, the timeout will still be installed by GtkNotebook's
handler, but since it returns FALSE, it will never get the matching
drag-leave event, causing it to trigger also when the mouse pointer
moved elsewhere before it expired.
Fix this by returning TRUE from drag-motion when the event is over a
tab. Note that this makes automatic tab switching not work anymore when
drag and drop is handled in the tab label widget; applications are
expected to also handle tab switching if desired in such a case.
https://bugzilla.gnome.org/show_bug.cgi?id=684415
GtkScrollbar used to rely on style-updated being emitted every time
after the widget was created in order to set the right values from its
style properties on GtkRange.
Nowadays we try to be smarter and avoid emitting style-updated at
creation time, so we need to manually initialize the GtkRange values.
This fixes a regression from 35e36b9fe5.
https://bugzilla.gnome.org/show_bug.cgi?id=686280
Currently we use gtk_style_context_set_background() when the state flags
change in order to propagate the background color to the overshoot
window, but this is actually only needed because the window doesn't get
expose events, since we always draw a full background in draw().
This also fixes some problems when the GdkWindow of the scrolled
window's child is composited, as seen in oxygen-gtk3.
https://bugzilla.gnome.org/show_bug.cgi?id=686265
The implementation of transition for GtkCssShadowValue can return NULL
at least when the two values have a different inset; all other parts of
the GTK/CSS machinery (e.g. GtkCssArrayValue) handle this by returning
NULL too. Instead, GtkCssShadowsValue was returning an invalid value,
where "len" was set, but some values in the array were NULL, which would
lead to a segfault when this value is later evaluated by the compute
function.
Fix this by making GtkCssShadowsValue return NULL if a shadow transition
fails, like GtkCssArrayValue does.
https://bugzilla.gnome.org/show_bug.cgi?id=686013
Don't use a repeating linear gradient, since it can't be easily
reftested against a non-repeating one for the reasons described in the
test header.
Instead, add a separate test for repeating gradients (against another
repeating gradient).
This makes the test pass, so it can be added to the Makefile now.
