Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
And with it, gtk_widget_get_visual() and gtk_widget_set_visual() are
gone.
We now always use the RGBA visual (if available) and otherwise fall back
to the system visual.
The cursor was set using gdk_window_set_cursor() even in
gdk_window_new().
So instead of having yet another flag, just make the users of that flag
call gdk_window_set_cursor() directly after the window was created.
Clip children to their window's size. That way no overdraw happens for
these widgets. But don't clip the handle.
We might in the future consider not clipping un-shrinkable children.
https://bugzilla.gnome.org/show_bug.cgi?id=762021
The GtkGesturePan behavior of locking onto certain orientations may
come across as confusing, and is not strictly necessary for mice and
other pointing devices.
As GtkGesturePan is also a GtkGestureDrag, we just use the same
callbacks on both gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=759670
This was causing problems in the case when only one of the paned
children is visible - we would use uninitialized memory, leading
to invalide clip regions. Concretely, the signal tab in the inspector
would sometimes not render at all.
Drop the margin misuse and use the border allocation of the
handle gadget. We use negative margins to make the border allocation
larger without pushing the paned children out.
Instead of having old and new style, now have a GtkCssStyleChange opaque
object that will compute the changes you are interested in for you.
This simplifies change signal handlers quite a bit and avoids lots of
repeated computation in every signal handler.
Use CHILD1/CHILD2 instead of 0 and 1, always use the same order and
don't check for child NULL-ness, because it will be done in
gtk_paned_set_child_visible anyways.
These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
This can be used by applications to indicate that a paned is expected
to be actively used by the users for configuring the UI, and needs
a prominent handle.
https://bugzilla.gnome.org/show_bug.cgi?id=738860
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
GtkPaned may just capture pointer events because the child widget
doesn't happen to have GDK_TOUCH_MASK set, resort to checking the
device in that case.
Dragging is all handled by a GtkGesturePan now, matching the
paned orientation.
On touch events, a wider area is listened for, so touch events
don't need to be as accurate to initiate dragging, if no dragging
is truly initiated in this case, events are just forwarded for
child widgets to handle.
This should allow theme developers to use a very small width for
the resize handle, but still let users easily move the handle by
defining a wider resize area.
The additional resize area follows the "margin" style property.
https://bugzilla.gnome.org/show_bug.cgi?id=728073
