GitLab

GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.

The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.

The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.

Restructure the getters for event fields to
be more targeted at particular event types.

Update all callers, and replace all direct
event struct access with getters.

As a side-effect, this drops some unused getters.

Events are refcounted structs, and we generally don't
pass these as const.

We want to make events readonly, so stop translating
their coordinates and instead pass the translated
coordinates separately, when propagating events.

On touchpads gtk_gesture_get_sequences() was called without a
corresponding g_list_free(). The same was true for touchscreens
if due to some reason only a single sequence was found.

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

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.

To some extent, pad and touchpad gesture events need extra API.

This avoids pointless allocations

We let these through in GtkEventController::filter, and handle
these especially on GtkGesture::update.

This prevents some of our generic object implementation tests
from working with gesture objects. Instead, add g_return_if_fail
checks in all the gesture constructors.

Whether the gesture is active or recognized should be checked before in
callers, or just not used naively.

Matthias Clasen authored May 05, 2014 and Carlos Garnacho committed May 23, 2014

For now, at least. We do this by hiding the instance and
class structures in private headers.

This gesture implementation recognizes rotations when fed with
events from two different GdkEventSequences