So we can use that one when translating event coordinates. Also adapt
the widgetfocus demo to ensure this works.
We should probably at some point delete either the int or the double
version.
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.
The result won't be visible anyway. This also prevents problems with
widgets that create some resource the size of the widget, like
GtkGLArea. It also keeps us from snapshotting revealers with
size 0.
The main GDK thread lock is not portable and deprecated.
The only reason why gdk_threads_add_idle() and
gdk_threads_add_idle_full() exist is to allow invoking a callback with
the GDK lock held, in case 3rd party libraries still use the deprecated
gdk_threads_enter()/gdk_threads_leave() API.
Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing idle callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
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.
