Move the glyph caching api to something that can support using
multiple textures. We now split the text render ops into multiple
ops for different textures, and make each op render just a substring
of the text node's glyph string.
gdk_seat_default_grab() grabs POINTER_EVENTS if the capability is
GDK_SEAT_CAPABILITY_ALL_POINTING. But that enumerator is a union that
includes GDK_SEAT_CAPABILITY_TOUCH, but we never grabbed TOUCH_EVENTS,
an unused macro that was presumably created with this purpose in mind.
So, check which of the ALL_POINTING capabilities we have, and set the
right mask of POINTER_EVENTS and/or TOUCH_EVENTS as required.
As part of this, explicitly let TABLET_STYLUS take over pointer events,
as this is the intended behaviour and was the effective result before.
This should fix touch events being lost in migrating from Device.grab()
to Seat.grab(GDK_SEAT_CAPABILITY_ALL_POINTING), as found by Inkscape.
https://bugzilla.gnome.org/show_bug.cgi?id=781757
The behavior where a touchpoint takes over the pointer position is
really backend dependent. Since this went away from the generic code,
implement it here.
This was by all lights broken, and is basically an implementation detail
of the X11 backend since the pointer emulating touch just steals the pointer
cursor, so should be reimplemented there.
One used to point to the toplevel and the other to the client-side window
that the pointer pointed to. The latter was made to be like the former in
most places, so put those together, and fix the remaining cases where the
variable might not end up with a toplevel/native window.
This is not necessary now that there's no client-side windows to track.
The only removed piece that could make sense is emission of grab broken
events, but it's already an stretch since the semantics of those with
multi-touchpoint is unclear.
Anyhow, This should be fixed at the GTK level, while we let GDK deal with
seat/device level grabs.
GDK just needs to care about toplevels nowadays, which means these events
are already delivered from the windowing. We don't need to generate
intra-window crossing events ourselves.
Those should be interpreted by widget-local gestures, not guessed at a
high level with no notions of the specific context. Users will want
GtkGestureMultiPress to replace these events.
Those worked similarly to those in GtkFlowBox, but would additionally
handle "active" state for child rows. Simplify this to just enabling/
disabling active state on gesture press/release, we don't get the
nice state updates when hovering around with a mouse button pressed,
but the rationale from flowbox applies here, and makes a nice cleanup.
They just maintain priv->in_button and widget state up-to-date, this
basically matters during user interaction, and is already maintained
in the gesture ::update handler. This seems to be sufficient.
Those basically controlled priv->active_child_active, which would
1) trigger a redraw when the pointer enters/leaves it, and 2) ensure
that press/release happen on the same child for it to be activated.
The former is not necessary, and the latter can be simplified by
just checking again the child on the coordinates given by the
::release gesture handler. This makes all enter/leave/motion_notify
event handlers unneeded.
All kinetic scrolling initial velocity calculations are now
taken from the scroll controller. The handling of timeouts
to snap back when overshooting has been also made to just
apply on devices that can't emit ::scroll-begin/end.
This is a GtkEventController implementation to handle mouse
scrolling. It handles both smooth and discrete events and
offers a way for callers to tell their preference too, so
smooth events shall be accumulated and coalesced on request.
On capable devices, it can also emit ::scroll-begin and
::scroll-end enclosing all ::scroll events for a scroll
operation.
It also has builtin kinetic scrolling capabilities, reporting
the initial velocity for both axes after ::scroll-end if
requested.
This change is made for consistency, it doesn't make sense to expose
one-way propagation, as it can only break expectations from GTK+. This
function might be made entirely private in the future, but it still
makes sense to do this in one go for our internal usecases.
This will allow further cleanups and optimizations in capture/target/bubble
event delivery. For simplicity, ATM every widget will receive its own
GtkEventControllerLegacy, it could be desirable to add finer control over
this in the future, so widgets that fully use event controllers for input
management can do away without this legacy piece.
