Yesterday I converted the /gtk/examples/drawing.c from gitlab to Nim to get more familiar with Gestures and the missing events like “draw” and “event-configure” and such. No real problem, gestures makes indeed some sense, but rewriting apps like InkScape to GTK4 gestures seems to be some effort.
But the funny fact was that I had to call GC_Ref() on the Gesture objects to keep them alive. Well a temporary ugly fix. So the Gesture GObjects do not behave like Widgets. I just hacked in a few print() statements into drawing.c as
drag = gtk_gesture_drag_new (); if (g_object_is_floating(drag)) g_print("is floating"); g_print ( "ref = %d\n", G_OBJECT ( drag )->ref_count ); gtk_gesture_single_set_button (GTK_GESTURE_SINGLE (drag), GDK_BUTTON_PRIMARY); gtk_widget_add_controller (drawing_area, GTK_EVENT_CONTROLLER (drag)); if (g_object_is_floating(drag)) g_print("is floating"); g_print ( "ref = %d\n", G_OBJECT ( drag )->ref_count );
$ ./drawing ref = 1 ref = 1
So the Gesture objects are not floating, and have a ref_count of 1 from the beginning, gtk_widget_add_controller() does not increase the refcount.
That is very different from the behavior of widgets, which start floating with refcount 1, and when we add the widget to a container widget that container takes ownership. Well for widgets and most other GObjects our Nim bindings works fine by using the toggle references framework from GObject. For gestures we have to fix it.
I wonder if all the other language bindings work already fine with the GTK4 Gestures. The fact that adding the Gesture to a widget does not increase the refcount seems to be a bit problematic. Of course we can patch the constructors like newDragGesture() so that the Nim GC will never collect it. But the ideal case would be that the GC collects gestures when they are not added to a widget and then go out of scope. And the last question: Do we have in GTK4 other GObject based types that behave with refcount like Gestures? Then we would have to care for them as well.