We don't want to expose the GtkCrossingData struct, and manually
feeding events to event controllers is not something we want to
encourage, going forward.
We want to make events readonly, so stop translating
their coordinates and instead pass the translated
coordinates separately, when propagating events.
... and use them.
Also, rename them from is/contains-pointer-focus to is/contains-pointer,
that's clear enough and not too long.
Finally, adapt the semantics of contains-pointer to mirror
GtkEventControllerKey::contains-focus. If is-pointer is set, so is
contains-pointer, they are not exclusive.
Which is what all users of this property wanted, too.
This adds specific marshallers for all of the locations where a generic
marshaller is being used. It also provides va_marshallers to reduce the
chances that we get stack traces from perf going through ffi_call_unix64.
This is forward ported from gtk-3-24.
# Conflicts:
# gtk/gtkeventcontrollerkey.c
# gtk/gtkeventcontrollermotion.c
# gtk/gtkgesture.c
# gtk/gtkgesturemultipress.c
Add boolean properties, is-pointer-focus and
contains-pointer-focus, that track whether the pointer
is in the widget itself or in one of its descendants.
The ::enter and ::leave signals get emitted up and down the
connecting path between the old an the new pointer location.
The signals are less useful if you can't find out where along
the path you are. That is what crossing mode and detail are
about, so add those to the signals.
The idea is that GTK+ 4 will be an epoch, API-wise.
Everything that was around for 4.0 has been there
since the beginning of the epoch and doesn't need
markers.
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
