GNOME Bugzilla – Bug 695894
Drag and drop creates "ghosts" that later appear as if letting go of a dragged item
Last modified: 2013-03-20 18:58:39 UTC
A weird phenomenon: if you wait long enough after testing drag and drop (maybe 2-5 minutes), you sometimes will see some sort of drag operation being “released” on the screen (ie: you see the icon/clip thumbnail being dragged across the screen for 0.5 seconds, even though you’re not touching the mouse). An easy way to reproduce this is in pitivi is to drag a couple of effects into the clip properties’ effects list, and wait a few minutes. Perhaps we’re not properly ending/cleaning up a drag operation and GTK times out after a while. This happens both with Pitivi git with GTK3, and Pitivi 0.15.
For the record, the drag "ghost" will precisely 5 minutes after each drag. This is certainly a timeout occuring in GTK due to us forgetting to handle something. Another clue is that I think this only affects the effects library, not the media library.
Turns out the "drag_end" signal was emitted by the drag source only after 5 minutes when you successfully drag and drop to a valid target, but if you try to drop on an invalid target you get the drag_end signal immediately. <owen> [that means] you are taking the drop, but not actually signaling that the drop is over <nekohayo> the receiving end has to manually emit the drag_end signal? <owen> mm, no, drag-end is something you get on the sending side when the receiving end finihses the drag. If you include GTK_DEST_DEFAULT_DROP in gtk_drag_dest_set (see docs for that) then you dont' have to call gtk_drag_finish(), but otherwise you do.
commit d5bd8dc02503e35658548e129bab25b7a3f50031 Author: Jean-François Fortin Tam <nekohayo@gmail.com> Date: Wed Mar 20 14:51:47 2013 -0400 clipproperties: Prevent drag and drop "ghosts" from the effects library Ensure that dragging and dropping an effect triggers the drag_end signal; using the "DROP" (or "ALL") flag for default DragDest allows us to correctly signal the end of the drag and drop without calling drag_finish() ourselves. Fixes bug #695894