This last slave device (stored per master) is used to fill
in the missing slave device in synthesized crossing events
not directly caused by a device event (ie. due to configure
events or grabs)
Fixes the situation where overshooting in scrolled windows with a
small viewport could end up overshooting right to the opposite
side, and then back again indefinitely.
Request automatically more motion events in behalf of
the original widget if it listens to motion hints. So
the capturing widget doesn't need to handle such
implementation details.
If the widget which events are captured listens to motion hints, there
are situations where neither the scrolled window or the child widget
request more motions.
The maths being used didn't resemble much about velocities or
friction/deceleration, so reimplement it in terms of velocity
vectors and decelerations, measured in pixels/ms^2.
Overshooting is also handled within the deceleration effect,
turning into a constant acceleration vector in the opposite
direction so it returns elastically within the boundaries.
An extra GdkWindow has been added, this window is the parent
of the child widget, and is the one getting resized/moved when
overshooting.
The unclamped adjustments' values are also stored in
GtkScrolledWindowPrivate as a separate value, overshooting is
pretty specific to GtkScrolledWindow and it isn't worth to
expose API in GtkAlignment for this single purpose.
This method allows GtkScrollable children to be blissfully
unaware of overshooting, as otherwise they'd have to handle
rather odd adjustment values themselves.
The innermost scrolled window always gets to capture the events, all
scrolled windows above it just let the event go through. Ideally
reaching a limit on the innermost scrolled window would propagate
the dragging up the hierarchy in order to keep following the touch
coords, although that'd involve rather evil hacks just to cater
for broken UIs.
When clicked again close to the previous button press location
(assuming it had ~0 movement), the scrolled window wil allow
the child to handle the events immediately.
This is so the user doesn't have to wait to the p-a-h timeout
in order to operate on the scrolledwindow child.
Store the device, and unset private fields whenever the device
is shadowed by another GTK+ grab, so popping up menus while
selecting (i.e. press-and-hold) doesn't leave it in a confused
state.
Move g_return_if_fail() stuff from the backends to the public
functions in gdkscreen.c itself, and some fixes for ugly formatting in
the various gdkscreen-backend.c files.
No need to subtract focus line width again, since the progressbar is
rendered starting at (0, 0).
This also fixes the entry-progressbar-coloring reftest.
The file "installation" part needed a long-overdue update, especially
as some headers were simply moved into gtk/deprecated and some new headers
were introduced, and a new .gschema.xml file needed to be processed.
