Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
We want to deliver crossing events to controllers
with scope same-native as long as at least one of
the targets is on the same native. As a new approach,
treat out-of-scope targets like NULL, and deliver
crossing events as long as one of the targets is
not NULL.
Instead of comparing two GtkWidget*s by casting the two GtkNative*s, we
can as well compare two GtkNative*s. Also if gtk_widget_get_native()
returns NULL, the code previously failed.
Instead of relying on gdk's antiquated crossing events,
create a new GtkCrossingData struct that contains the
actual widgets, and a new event controller vfunc that
expects this struct. This also saves us from making sense
of X's crossing modes and details, and makes for a
generally simpler api.
The ::focus-in and ::focus-out signals of GtkEventControllerKey
have been replaced by a single ::focus-change signal that
takes GtkCrossingData as an argument. All callers have
been updated.
We want to make events readonly, so stop translating
their coordinates and instead pass the translated
coordinates separately, when propagating events.
This is the first step towards refactoring how widgets deal with event
controllers.
In the future, the widget will treat controllers the same way it treats
child widgets:
1. The controllers will be created without a widget.
2. There will be gtk_widget_add/remove_controller() functions to add
or remove controllers.
3. The widget will hold a reference to all its controllers.
This way we will ultimately be able to automate controllers with ui
files.
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.
This will be used right before handle_event() in order to filter
out events, useful to make the previous "no touchpad events" behavior
the default, and have gesture subclasses include manually the touchpad
events they handle.
There are two scenarios. A widget sub-class owns a GtkEventController
and passes itself to it, or a controller owned by something else is
passed a widget.
In the second case, if the widget is destroyed before the controller,
we will have a crash when destructing the controller because we will
be accessing invalid memory. Adding a weak reference on the widget
addresses that problem.
This leads to a crash in the first case. When the widget is getting
destroyed, it will drop the reference to its own controller. The
controller will skip touching the widget because the weak reference
would have turned it to NULL. However, when the widget sub-class chains
up to GtkWidget it will try to free all the controllers in its list.
Unfortunately, all these controllers have already been destroyed. So
we need to guard against this too.
https://bugzilla.gnome.org/show_bug.cgi?id=745225
Those might trigger the destruction of some widget that would dispose the
event controller while the event is still being handled, so keep an extra
ref on the controller during event processing.
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.
