I’ve been working on trying to get Ark’s drag and drop to work again, and one of the goals I set is to get it more stable than before. One of the most important things to me then was to trash the old method, which was to first extract the file when the drag was started, and then let the user place it. This failed bad whenever you would try to drag a large file from ark and annoyed many a user.
So I thought, this time I’ll find a way to extract the info only when the drag is actually successfully completed. So following a tip from David Faure on irc, I happily started implementing QMimeData and making my own extract-files custom mimedata class. It would work by extracting the file when retrieveData is called, while at the same time showing a progress dialog. Now, laying some weird interactions with dolphin aside, what surprised me was the buggy behavior I saw once the extractions actually took more than 5 seconds. I eventually found this limit to be exactly five seconds, and grepping around in qt’s kernel classes, in the x11 dnd implementation I found this:
// timer used to discard old XdndDrop transactions
static int transaction_expiry_timer = -1;
enum { XdndDropTransactionTimeout = 5000 }; // 5 seconds
I didn’t dig much more than this, because some google searches also seemed to confirm that getting drag and drop implementations seem to be mostly timeouted. So what do I do know? Is this a bug in the dnd implementation, or am I simply trying to use drag/drop the wrong way? Is there another way I can do this? To simplify, here are the constraints I am trying so hard to get around:
- The solution must be using drag and drop
- The destination application will only receive a “text/uri-list” mimedata object with the location of temporarily extracted files (ie no custom mimetypes the receiving app needs to have implemented)
- The extraction should only take place once the drag has been completed successfully
- The extraction should be allowed to take long times (people extract really large stuff these days), without bugging up either the source or destination application.
So is there a way out of this?
Oh, and if you’d like to try my test application for these long delays, it can be found here.
EDIT: The blog linked me automatically to an entry about XDS: http://en.wikipedia.org/wiki/Direct_Save_Protocol
Might this be what I want?
Harald's hacks 
July 17, 2008 at 10:56 am
Can you avoid getting the information? Perhaps you do not need it until the file is dropped for minimal DND support.
If you get the info in the background, you can still use it once it becomes available.
July 17, 2008 at 11:04 am
@Jos: I thought about doing that; starting the extraction asynchronously and then set the mimedata once the extraction has finished. But this would still fail bad once (extractionTime – timeForUserToDrag) > 5 seconds
July 17, 2008 at 11:33 am
There’s another problem with synchronous extraction – people with small temp spaces needing to extract large files. If you extract the file while draging it will be unpacked to /tmp or something, right? Well my Root disk for one is only meant for my system files, so I don’t really have the space required to unpack a DVD ISO or something if it first must be saved to a temp space.
July 17, 2008 at 11:38 am
the audiocd:// kioslave used to handle drag n drop very nicely.
You could drag the “ogg vorbis” folder from the audiocd:// Folder to your desktop and
it would be transcoded on the fly. So there is a solution.
Have a look there maybe ?
July 17, 2008 at 12:01 pm
knowing nothing of X and qt drag dropping i’ll throw this in anyhow,
can you hook and eat the drop event/message, store the destination, unpack the file(s), then fire the drop with the real file list?
@kaminix, can’t see a problem with seeing what’s available, and if you are going to go over what’s there in /tmp prompt for a location.
July 17, 2008 at 2:25 pm
On Windows it’s even worse because retrieveData is getting called at the time when dragging starts (blame it on the OLE implementation).
IMHO drag and drop with qt still sucks a little bit. You also do not have enough control over the drop actions while the user drags the cursor around.
E.g. I would like to forbid the “move” action when one of my objects is moved on the desktop but I would like to allow the “move” action when the drop target is one of my own widgets. Don’t know how to properly code this because you cannot modify the supportedActions after a QDrag object has been created.
July 17, 2008 at 3:05 pm
XDS would be nice. Thunar, File roller, and Nautilus all use it, so we’d get interoperability with them for free. In fact, I think it would be interesting to see XDS put into kdelibs and maybe an extensive drag-to-save framework integrated. (e.g. what rox does or the GIMP’s unsaved documents dialog.)
July 17, 2008 at 10:15 pm
I don’t think there is… unless… unless you submit a tar:/ or zip:/ URI for the drop target. Honest, XDND sucks because the receiving app is the one who gets to handle the stuff. So the only way to make it work with KDE at least is to submit KIO URIs.
July 18, 2008 at 6:11 am
So, the way XDS works, the source does the work, which seems to be the goal. All the drop target does is provide the source with the save directory (by setting a window property) and react to some status stuff from the source (error, success, etc.). The actual saving is done directly by the source.
July 18, 2008 at 10:06 am
XDS seems interesting, although I didn’t quite catch how it works.
I was just thinking of a possible solution: in the latest gnome release, using gvfs (the successor to gnome-vfs), there’s a FUSE filesystem that interfaces with gvfs, so that when you drag a remote file from nautilus to another app, it can open remote files, because it gets a local url to the remote filesystem (like ~/.fuse/someremotesystem/file).
Maybe a fuse-to-ark filesystem, that would get something like ~/.fuse/some-file-uuid-or-name/internalfile that would do the decompression on demand when the receiving app uses the normal unix read().
July 21, 2008 at 4:17 am
XDS seems to be what you want. It’s built atop XDND.