GNOME Bugzilla – Bug 147529
Drag and Drop Enhancement
Last modified: 2004-12-22 21:47:04 UTC
I was playing around with file-roller today and stumbled into the following "bug": http://bugzilla.gnome.org/show_bug.cgi?id=102501 From comment #4, it looks like as soon as the user lets up on the mouse (at the end of the drag operation) the drag-and-drop operation is finalized automatically by GTK...e.g. the target window recieves the go-ahead. It seems like there might need to be some primitive present in GTK+ to handle the case where a user's let up on the mouse button but the source application needs to do some housekeeping before the target application takes control. I checked the XDND spec, which I understand is one of the two specs GTK+ uses for drag-and-drop: http://www.newplanetsoftware.com/xdnd/ and it seems to me that this is already handled, in Step 7: "If the mouse button is released in the window, the source waits for the last XdndStatus message (if necessary) and then sends a ClientMessage of type XdndLeave or XdndDrop, depending on the 'accept' flag in the last XdndStatus." Is this something that GTK+ could feasibly implement? Or does it already implement this, just in a way I've missed? Or are there reasons this can't be implemented below XDND?
FileRoller could block DND and not respond with the filename until the operation completed with the current API. Blocking the DND with the drag icon sitting there while the files were being extracted though isn't very good from the from the user's point of view however, and GTK+ is going to time out after a couple of minutes. You really need establishing the connection between the destination location and fileroller to be free and to have fileroller extract into the destination location instead of having a pointless temporary directory. You could do this with a private protocol - say something like _NAUTILUS_SAVE_URI_LOCATION target which is a pair of an XID and X property and nautilus stores the URI to extract into into that location after receiving the drop. Or you could use the XDS save protocol which basically is designed for this purpose already. http://www.newplanetsoftware.com/xds/ I think that's implementable in terms of GTK+ DND API, though I'm not a huge fan of the protocol and it also blocks the drop completion until the data is transferred. Anyways, I don't know any GTK+ addition that makes sense here; pretending that the user hasn't released the mouse until the 200M tarball has finished untarring is just inviting the user to reboot the machine.