[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