gtk3to4: Start working on deprecations for Gtk4: Event Controllers
Operating System: All
Description of the feature
In order, some day to consider moving to Gtk 4, it would be valuable to start eliminating deprecations ins Gimp 2.99. This issue is for tracking "Stop using GtkWidget event signals".
In working on this, the documentation is quite sparse and vague.
I've discovered that callbacks have to be rewritten in order to work properly. Also, there is no indication of which event triggered the callback, so this has to be baked into either having different callbacks for different events, or bundling some metadata into the call.
From Gtk documentation
https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-gtkwidget-event-signals
####Stop using GtkWidget event signals####
Event controllers and gestures replace event signals in GTK 4.
Most of them have been backported to GTK 3.x so you can prepare for this change. [ed: this is very misleading as the actual list of backported events is below]
Signal | Event controller | Backported to Gtk 3 | Completed Gimp? |
---|---|---|---|
::event | GtkEventControllerLegacy | NO | |
::event-after | GtkEventControllerLegacy | NO | |
::button-press-event | GtkGestureClick | NO | |
::button-release-event | GtkGestureClick | NO | |
::touch-event | various touch gestures | DON'T KNOW | |
::scroll-event | GtkEventControllerScroll | YES | |
::motion-notify-event | GtkEventControllerMotion | YES | |
::delete-event | - | DON'T KNOW | |
::key-press-event | GtkEventControllerKey | YES | In Progress !548 (closed) |
::key-release-event | GtkEventControllerKey | YES | In Progress !548 (closed) |
::enter-notify-event | GtkEventControllerMotion | YES | |
::leave-notify-event | GtkEventControllerMotion | YES | |
::configure-event | - | DON'T KNOW | |
::focus-in-event | GtkEventControllerFocus | NO | |
::focus-out-event | GtkEventControllerFocus | NO | |
::map-event | - | DON'T KNOW | |
::unmap-event | - | DON'T KNOW | |
::property-notify-event | replaced by GdkClipboard | NO | |
::selection-clear-event | replaced by GdkClipboard | NO | |
::selection-request-event | replaced by GdkClipboard | NO | |
::selection-notify-event | replaced by GdkClipboard | NO | |
Drag-and-Drop signals | GtkDragSource, GtkDropTarget | YES, NO | |
::proximity-in-event | GtkGestureStylus | YES | |
::proximity-out-event | GtkGestureStylus | YES | |
::visibility-notify-event | - | DON'T KNOW | |
::window-state-event | - | DON'T KNOW | |
::damage-event | - | DON'T KNOW | |
::grab-broken-event | - | DON'T KNOW |
Event signals which are not directly related to input have to be dealt with on a one-by-one basis:
If you were using ::configure-event and ::window-state-event to save window state, you should use property notification for corresponding GtkWindow properties, such as GtkWindow:default-width, GtkWindow:default-height, GtkWindow:maximized or GtkWindow:fullscreened. If you were using ::delete-event to present a confirmation when using the close button of a window, you should use the GtkWindow::close-request signal. If you were using ::map-event and ::unmap-event to track a window being mapped, you should use property notification for the GdkSurface:mapped property instead. The ::damage-event signal has no replacement, as the only consumer of damage events were the offscreen GDK surfaces, which have no replacement in GTK 4.x.