If you load the draggableicons and set a breakpoint in the drop() handler, you can see that just clicking the mouse on a bitmap and releasing it in place will not cause a drop event. Instead, you get a Qt::IgnoreAction.
This has broken the way I do mouse handling in several working Qt 4 applications. Someone probably did it on purpose as an "optimization", but I consider it a bug. That's because I use "internal drags" as a substitute for ordinary mouse handling once a button has been pressed, due to the robustness of drag & drop (with respect to things like Alt-Tab, for instance).
My feature is not necessarily the only one where a programmer could want to distinguish a mouse release in place from a cancellation, e.g. with ESCAPE. But for a motivating example of what I've done with this technique, see:
I'm on Kubuntu 13, but it may be something that each platform plug-in does differently. The behavior does not seem to be a property of the settings used, rather a limitation of the drag and drop engine. The cause is presumably somewhere in:
I would suggest that the first thing a drag and drop do is call back with a dragMoveEvent() at the current location (to get the drop disposition). This puts the application developer in control of whether to accept or reject it; a strictly more powerful proposition than the current behavior.