Gesture DnD and Focussing Issues / Gtk4

pyzahl · August 24, 2026, 6:11pm

I am having random problems (occasionally only) hard to reproduce predictably:

I am moving objects in a canvas using the gesture/event controller like this:

        GtkEventController* motion = gtk_event_controller_motion_new ();
        g_signal_connect (motion, "motion", G_CALLBACK (drag_motion), this);
        gtk_widget_add_controller (canvas, GTK_EVENT_CONTROLLER (motion));
        g_object_set_data (G_OBJECT (canvas), "motion-controller", motion);

github.com/pyzahl/Gxsm4

core-source/app_view.cpp

master


      
                          GType types[] = { GDK_TYPE_FILE_LIST }; //, G_TYPE_FILE}; // appect multiple file to add as movie
                          //GType types[1] = { G_TYPE_FILE }; //, GDK_TYPE_FILE_LIST }; // file type only
                          gtk_drop_target_set_gtypes (target, types, G_N_ELEMENTS (types));
                          g_signal_connect (target, "drop", G_CALLBACK (AppBase::gapp_load_on_drop_files), GINT_TO_POINTER (ChNo));
                          gtk_widget_add_controller (canvas, GTK_EVENT_CONTROLLER (target));
                  }
                  // Actions
                  obj_drag_start = false;
                  pointer_coord_display = false;
          
                  GtkEventController* motion = gtk_event_controller_motion_new ();
                  g_signal_connect (motion, "motion", G_CALLBACK (drag_motion), this);
                  gtk_widget_add_controller (canvas, GTK_EVENT_CONTROLLER (motion));
                  g_object_set_data (G_OBJECT (canvas), "motion-controller", motion);
          
          #if 0
                  // testing, do not need
                  GtkDragSource *source = gtk_drag_source_new ();
                  gtk_drag_source_set_actions (source, GDK_ACTION_COPY | GDK_ACTION_MOVE);
                  g_signal_connect (source, "prepare", G_CALLBACK (drag_prepare), this);
                  g_signal_connect (source, "drag-begin", G_CALLBACK (drag_begin), this);

It usually works all fine.

But at some circumstances I may loose focus or some thing gets out of sync and I can not regrab an object.

Also happens at times: Possible related to moving the mouse out of the window area? I loos total control to the whole app.
No mouse or kbd input possible any more, while it is still fully operational and I can remote (via a SHM python bridge) do anything…
But I did not found any way to regain local control. Anything else and other apps are ok.
I can still move resize my app’s windows.

Another weird issue with window keyboard accelerator functions:
Some times a for sure focused window is not receiving (nothing happens) a to it’s window assigned kbd accelerator functions.
And worse, at times those get executed for am different window?!?
Some times I simply need to push the key a few times to finally receive the action. Simply odd.

What is going on here? Anything I can do or should fix? I never had such issues with Gtk3.

Those symptoms happened also previously on X11 but are the same on Wayland where I lately moved to (or was forces to as of discontinuated support for X11) but discover more and more flaws even unrelated to my application.

gwillems · August 25, 2026, 3:15pm

Hi,

I’m not sure Gtk.EventControllerMotion is the most appropriate event controller for tracking drags.

Have you tried using the motion signal of a Gtk.DropTarget? It should better complement the Gtk.DragSource.

Alternatively, a Gtk.GestureDrag could be something to look at.

That would help to know which gtk version and with desktop environment you use, and if GNOME if you installed extensions. Check also for warnings in the console.

pyzahl · August 26, 2026, 6:45pm

The problem exists now unchanged over many gtk4/gnome versions, from early gtk4 generation to the very latest (Gnome Shell 50.3 / Debian Testing).

It may coincide with simultaneous move/click events. Any chance a click event is been dropped while moving or start moving?

Mainly I manage objects tweaking (the usual way): via click (button down) on a object handle with a following motion until (release of button) to set the new position.

But some times it’s stuck, as if a button release or so got missed – may be if click/release comes together with motion (not holding the mouse steady) it’s not getting the events in the right order – may be?

I am trying to figure out a pattern. Some times it hard to reproduce at all, all works, and then sudden it just happens right away later.
So my “logic” can not be wrong.

No extensions.

gwillems · August 27, 2026, 7:44am

That would be great to have!

Is it for all gtk apps, or just a specific one?
That sounds like the mainloop is unable to process events. If only one app is affected it could be a threading issue (something preempts the mainloop, or gtk APIs are called from a non-mainloop thread).

pyzahl · August 27, 2026, 1:50pm

I do use a lot of threading for time critical data processing and moving.
But I do (hopefully not missed any) not call gtk functions out of threads.

All those required interactions are done via thread triggered gtk_idle or gtk_timeout calls.

So you say there may be some thing related to a “missed” out of main loop sync call going on?
Or can a heavy loaded main loop, drawing, etc. cause misbehavior?

Any idea how to locate such an potential issues?

The “lost focus” is a very rare situation and only effected my app.

gwillems · August 27, 2026, 2:47pm

The default priority of gtk_timeout is GLib.PRIORITY_DEFAULT , which is the same as input events, so if the timeout handler is called frequently or during a long time that may block events processing.

If it’s the case you may use GLib.timeout_add_full to specify another priority value (higher numbers have lower prio).

Another potential issue: if you use GTask to start a lot of threads, you may be hit by this bug.

pyzahl · September 1, 2026, 5:13pm

Hello again,

I am not yet 100% sure, but it seams after the update to Gnome 50.4 some behaviors improved a lot incl. those focus & DnD issue – at least did not yet happened again! I
ll keep watching and testing “life”…