After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695894 - Drag and drop creates "ghosts" that later appear as if letting go of a dragged item
Drag and drop creates "ghosts" that later appear as if letting go of a dragge...
Status: RESOLVED FIXED
Product: pitivi
Classification: Other
Component: Effects
0.15.x
Other Linux
: Normal minor
: 0.91
Assigned To: Jean-François Fortin Tam
Pitivi maintainers
Depends on:
Blocks: 682886
 
 
Reported: 2013-03-15 03:03 UTC by Jean-François Fortin Tam
Modified: 2013-03-20 18:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jean-François Fortin Tam 2013-03-15 03:03:05 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.
Comment 1 Jean-François Fortin Tam 2013-03-20 17:10:19 UTC
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.
Comment 2 Jean-François Fortin Tam 2013-03-20 18:51:59 UTC
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.
Comment 3 Jean-François Fortin Tam 2013-03-20 18:57:43 UTC
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