[Qt-interest] Both way Drag n Drop

Hostile Fork hostilefork at gmail.com
Sat Sep 19 19:36:13 CEST 2009


> From: "Puneet Bisht" <pbisht at nivio.com>
> Subject: [Qt-interest] Both way Drag n Drop

> My Application is Showing Remote files,I can download them on my  
> system as
> well as a file can de uploaded also using darg n drop mechanism .
> But I've been struggling for a while implementing drag n drop on  
> download.
>
> Can anyone suggest me how to implement both side drag n drop .


Hi Puneet,

It's generally easier to answer questions when the person asking  
explains what they've tried, what specifically didn't work, and the  
nature of the dead ends they found!  But...since I've looked at this  
issue myself, I'll put some of my thinking in writing.

I came to the conclusion: "simply do not do this".  The biggest reason  
is that when a network operation is involved, you are dealing with  
something that can take arbitrarily long and can also fail--or the  
user may want to abort it manually.  The cross-application drag and  
drop functions we have today are just too simple to handle that  
scenario well.  [It isn't really Qt's fault, as this is an OS issue.]

Beyond the semantics, there are matters of aesthetics.  Very few drop  
targets do their drop handling on separate threads.  So the target  
program will probably appear to be hung during the entire download-- 
even if it's going along smoothly!  In a 30 minute download, that  
means 30 minutes the user couldn't use the program they dragged the  
object into.  :(

The safest approach is to turn it into a two-step process.  One step  
to fetch a copy of the file locally into a staging area.  The user  
then moves the file out of the staging area if they want.  Practically  
all web browsers do it that way, and it's probably for the reasons  
I've outlined:

	http://www.chromefans.org/chrome-tutorial/how-to-manage-my-downloads-in-google-chrome.htm

Going into more detail to see the "semantic breakdown", you need to  
start with the delayed encoding Qt sample:

	http://doc.trolltech.com/4.5/draganddrop-delayedencoding.html

Firstly, getting the MIME type of the remote file beforehand it could  
be tricky with something like ftp.  But let's say you hack around this  
by guessing from the filename (e.g. "foo.html") and you decide  
hasFormat("text/html") was true.  The droptarget says that's something  
it can handle, so the user gets visual feedback and decides to release  
the mouse button.  Time passes while your retrieveData function blocks  
on the download.  What do you return if there's an abort?

Your options are a null QVariant, throw an exception, or partial  
data.  Though it's possible that not all clients would crash on all  
these cases on all OSes... my experience is that even even minor  
oddities can cause the drop target and/or drop source to crash most  
clients.  (FWIW: merely hitting a breakpoint while a drag and drop is  
in progress hangs all of KDE, at least under VMWare.  Sometimes to the  
point where I'm forced to reboot.)

*IF* you control both the code of the drop source and drop target, you  
can invent your own standard on top of drag and drop.  Then the MIME  
data you pass isn't the object itself, merely a way of establishing a  
connection.  "application/x-async-ftp-contract" could contain the  
address of shared memory objects which you use to implement a protocol  
about aborted downloads, percent progress, the data when it arrives,  
etc...

Of course that's not going to do you much good with Finder, Windows  
Explorer, or any other target that doesn't know what you're talking  
about.  Unless you run a background process which searches the  
filesystem for files of type "application/x-async-ftp-contract" and  
replaces them when-and-if the download completes, or erases them if it  
fails.  :)

(Note: I'm quite sure there are hooks in particular programs--e.g.  
Windows Explorer or Finder--that are analogous to the higher-order  
protocols.  But they're not within the scope of drag-and-drop itself,  
and won't work for drop targets in general.  It may be worth it to you  
to research those hooks if platform-specific hooks are acceptable to  
you.)

Hope this helps,
---Brian

http://hostilefork.com



More information about the Qt-interest-old mailing list