Merge lp://qastaging/~osomon/unity-2d/dnd2 into lp://qastaging/unity-2d/3.0

# Functional

It works well, but the cursor behavior is a bit weird. If I drag a file from Dolphin to the trash, I get the correct "Move" cursor, but if I drag it from Nautilus I get the "Copy" action. Not sure what is wrong here. Maybe Nautilus does not put "Move" in the proposed actions?

# Code

90 +
91 +public Q_SLOTS:
92 + /* Default implementation of drag’n’drop handling, should be overridden in
93 + subclasses to implement custom behaviours. */
94 + /* The 'event' parameters should be DeclarativeDragDropEvent*, but because
95 + of http://bugreports.qt.nokia.com/browse/QTBUG-13047 they need to be
96 + passed around from QML to C++ as QObject*. This is fixed in Qt 4.7.1. */
97 + virtual void onDragEnter(QObject* event);
98 + virtual void onDrop(QObject* event);

We ship Qt 4.7.1 in Natty, so you should already be able to use DeclarativeDragDropEvent* instead of QObject*.

I think you don't need to call setAccepted() in drop methods (onDrop() or dropEvent()). It only matters in drag methods (onDragEnter(), dragEnterEvent(), ondragMove(), dragMoveEvent()).

From what I understand, the dnd events are received in the C++ side, then forwarded to the QML side, which forwards them again back to C++. Which raise a question: is it necessary at all to go through QML?

Usual nitpick: "}\nelse {" => "} else {" :)

> It works well, but the cursor behavior is a bit weird. If I drag a file from
> Dolphin to the trash, I get the correct "Move" cursor, but if I drag it from
> Nautilus I get the "Copy" action. Not sure what is wrong here. Maybe Nautilus
> does not put "Move" in the proposed actions?

That’s exactly what happens. Not much we can do, apart from patching Nautilus itself…

> We ship Qt 4.7.1 in Natty, so you should already be able to use
> DeclarativeDragDropEvent* instead of QObject*.

Right. For some reason I thought we may want to backport this feature to maverick, which is mostly why I kept this workaround. I also must admit it is very convenient to be able to develop on maverick while I haven’t migrated to natty yet.

> From what I understand, the dnd events are received in the C++ side, then
> forwarded to the QML side, which forwards them again back to C++. Which raise
> a question: is it necessary at all to go through QML?

That’s how it works indeed, and I’d be more than happy to find a solution that would avoid the roundtrip between C++ and QML and back, which on top of this is perceivably slow. The issue is that the LauncherView doesn’t have direct knowledge of the list model, and much less of how to associate a mouse position to a LauncherItem. Any suggestion?

> We ship Qt 4.7.1 in Natty, so you should already be able to use
> DeclarativeDragDropEvent* instead of QObject*.

Fixed.

> I think you don't need to call setAccepted() in drop methods (onDrop() or
> dropEvent()). It only matters in drag methods (onDragEnter(),
> dragEnterEvent(), ondragMove(), dragMoveEvent()).

Verified and fixed, thanks for the tip!

> Usual nitpick: "}\nelse {" => "} else {" :)

Fixed too. I’ll never get used to it :/

All your comments have been addressed except the C++ to QML to C++ roundtrip, for which I welcome implementation ideas.

Let's keep that way for now. Approved.

How slow is "perceivably slow"? I doubt that if anything looking slow is because of the roundtrip between C++ and QML.

Please make my life easier and readd the workaround for Qt 4.7

Ignore my last comment, this feature will not be backported to Maverick.
Let's advise future OEM projects on Maverick or Lucid to use Qt 4.7.1

I understand now why it's "perceivably slow". In LauncherView::launcherItemAt you go through the whole scenegraph for _every_ move of the mouse. That is absolutely not acceptable.

I do not understand why the plan has changed:
LauncherView should not know about the list of LauncherItems at all. The LauncherItem should take care of their own drag&drop events, not only the actions on drop but also the detection of the drag. Why are not we creating a QML item that is able to do that similar to what is done in:

https://bitbucket.org/gregschlom/qml-drag-drop/src/e5dbe26c3073/DeclarativeDropArea.cpp

It would be less code, faster and also above all it will allow much greater flexibility.

Have a look at the revisions in my branch, that is how I had implemented it first.

It is not less code.

And it handles drag events only for launcher items, meaning that other (empty) areas of the launcher cannot receive drag events, which breaks the current functionality (drag’n’drop of desktop files and URLs).

It will be faster and more flexible.

I don't understand why can't you have the drag'n'drop of desktop files and URLs as you have them today, in the LauncherView and the rest in custom QML items.

Because if the LauncherView reimplements drag and drop event slots, it will eat the events and they won’t be propagated to the launcher items.

Also, I changed the implementation so as to allow implementing bug #607782: if we want "capable" launcher items to stand out when something is dragged over the launcher, the event needs to be handled by the view.