GtkGesture is a GtkEventController. gtk_event_controller_dispose() calls
_gtk_widget_remove_controller(). That NULLs the pointer-to-Controller in
our EventControllerData but does not delete said ECData from our GList.
Subsequently, if that same Widget gets unparent()ed, that method calls
unset_state_flags(), which leads to doing reset_controllers() if we are
insensitive. Now, unlike most most other loops over the GList of ECData,
reset_controllers() does not skip nodes whose pointer-to-Controller is
NULL. So, we call gtk_event_controller_reset(NULL) and get a CRITICAL.
This surfaced in a gtkmm program. The Gesture is destroyed before the
Widget. The Widget then gets dispose()d, which calls unparent()… boom.
I didn’t find an MCVE yet but would hope this logic is correct anyway:
The simplest fix is to make the loop in gtk_widget_reset_controllers()
skip GList nodes with a NULL Controller pointer, like most other such
loops, so we avoid passing the NULL to gtk_event_controller_reset().
In other, live cases, _gtk_widget_run_controllers() loops over the GList
and removes/frees nodes having NULL Controllers, so that should suffice.
But this clearly was not getting a chance to happen in the failing case.
https://bugzilla.gnome.org/show_bug.cgi?id=792624
We no longer emit this signal. You can use various gestures
and event controllers instead. If you need to catch raw
motion events, use the generic ::event signal.
This function is misnamed - it is only ever relevant for
windows. And with the ::hide-on-delete property , it is
no longer necessary to use the signal for this simple case.
These signals are no longer used in GTK+ and have a (not quite
perfect yet) replacement with GtkEventControllerMotion.
If you need to catch the raw events, the generic ::event
signal still works.
This signal is unused in GTK+ and configure events are handled
internally by GtkWindow.
If you need to catch configure events, the generic ::event
signal still works.
This signal is not used in GTK+, and has a suitable
replacement with GtkGesture and its subclasses.
If you need to catch the raw touch events, the generic ::event
signal still works, too.
This signal is not used in GTK+, and has a suitable
replacement with GtkEventControllerScroll.
If you need to catch these events, the generic ::event
signal still works, too.
Both GtkWidget and GtkContainer had similar docs regarding hfw/wfh
geometry management. Move these just to GtkWidget. Also make sure the
examples compile, port everything from gtk_preferred_* to measure and
replace some occurrences of "container" with "widget" where container
was just used to refer to a widget with child widgets.
Now all events structs are private, it doesn't make as much sense
having GdkEventPrivate wrapping allocating events. This is a first
step towards removing it.
It won't stand true anymore that the GdkEventType argument is the
first field of the GdkEvent* structs. All callers have been updated
to use event->any.type instead.
Mark the following signals as deprecated:
event, event-after, button-press-event, button-release-event,
touch-event, scroll-event, motion-notify-event, enter-notify-event,
leave-notify-event, property-notify-event, selection-clear-event,
selection-request-event, selection-notify-event, selection-received,
selection-get, proximity-in-event, proximity-out-event. Most
of these have suitable replacements in event controllers and
gestures already. The selection-related signals will soon be
irrelevant when selection handling moves to GDK.
Set G_ENABLE_DIAGNOSTIC=1 to see deprecation
warnings for uses of these signals.
