Drag and drop outside the application

[jpn]

Does anyone happen to have tried implementing a feature where you could drag and drop something outside the application, and a new window would be created as a result of the drop?

There is a feature like that for example in opera browser as I recall. You can drag and drop a tab outside opera's window and then a new window is created.

I have been playing around with this for a while but I can't figure out any working solution.
I am connected to QDrag::targetChanged(QWidget*) signal and the target seems always to be null when moving a drag outside my window.
Btw, I have tried to install an event filter on QApplication::desktop() but it seems to get never called..

Any tip would be highly appreciated!

[jpn]

I found a bit hackish way to do it. Not too elegant, but it's working at least on win2k+ (and somehow)..
I created a transparent top level widget covering the whole desktop area, and of course, accepting drops..

As window transparency needs a composition extension and manager on X11 and I didn't have the interest to start configuring them, I cannot say about Linux.

Anyway, I wish I found a better way to solve this..

Edit: oh, and in case anyone is interested to check it out:

[jpn]

It is basically impossible to use QDrag. Since it's based on MIME types, there is always some application which is (too?) liberal to accept drags. Like for example firefox seems to accept almost anything.. Also, detecting the drop point might be problematic if there's nothing accepting it (a reliable enough location could be retrieved with QCursor::pos(), though).

It seems to be fairly easy to do fancy "fake drag" effects by using QRubberBand the way QDockWidget does. So if anyone is ever stuck on the same problem, the answer is in QDockWidgetPrivate::mouse*Event().

[wysota]

It could be that Opera's drag really holds a mime object, which is accepted by the desktop and that Opera is then run by the desktop manager to handle the data. It could be that I am wrong too You could write to Opera developers asking for help. They use Qt3, but I'm quite sure a simmilar mechanism will work for Qt4.

There is an example application in Qt4 distribution which lists mime-types held by a drag if you perform a drop on the application's window. It's called droptarget or something simmilar.

[jpn]

There is an example application in Qt4 distribution which lists mime-types held by a drag if you perform a drop on the application's window. It's called droptarget or something simmilar.

Good idea! I checked it out and it doesn't seem to be a real drag object. Or at least the dropsite example doesn't accept it nor show any info..

By the way, Opera's drag works only in Windows. I'm not familiar with drag'n'drop stuff in WinAPI, but I get the feeling that it's not a real drag'n'drop at all..

[wysota]

It could be that it is making a screenshot of the desktop and using it as an overlay so that it knows that the drop was made "outside" the main window (based on coordinates), so you might have not dropped on the dropsite window but a window on top of it, which seemed to look "invisible". It's a crude but effective way of doing such things.

[jpn]

It could be that it is making a screenshot of the desktop and using it as an overlay so that it knows that the drop was made "outside" the main window (based on coordinates), so you might have not dropped on the dropsite window but a window on top of it, which seemed to look "invisible". It's a crude but effective way of doing such things.

This man is full of acute ideas! The only problem with this approach is that any animation or motion in other open applications would be ceased during the drag (unless the screenshot of the desktop is updated frequently, which might be a bit costly and cause flicker, I think). I tested Opera's drag once again and for example flash animations in mozilla keep going during the drag. So I believe it's just a custom top level widget in the same sense than QRubberBand in QDockWidget implementation.

[wysota]

Yeah, could be. Or the mask keeps the contents of the "screenshot" widget from being visible, but surely using a top-level widget makes more sense.