QGraphicsItem scenePos() broken after aborting previous item drag

[philw]

I believe that I see what's going on. I would call this a Qt bug.

The implementation of:
QGraphicsItem::mouseRelaseEvent (QGraphicsSceneMouseEvent*).

... normally clears this QGraphicsScene private data member:

QMap<QGraphicsItem*, QPointF>
QGraphicsScenePrivate::movingItemsInitialPositions ;

But forcing the QGraphicsItem to lose the mouse grab prevents a subsequent mouse release event from being sent to the QGraphicsItem, so that QMap is not cleared.

The movingItemsInitialPositions map must be empty for the QGraphicsItem:: mouseMoveEvent() implementation to populate its local 'initialPositions' copy of that QMap. And this is, I believe, the source of this problem.

I believe the correct fix would be for the QGraphicsScene's movingItemsInitialPositions QMap to be cleared when the scene's mouseGrabberItem asynchronously loses the grab (e.g. when the item is disabled).

Also, it would be useful if QGraphicsItem had a public 'dropMouseGrab()' method which did the same cleanup as does QMouseReleaseEvent().

In the mean time, instead of dropping the mouse grab (when the user hits the ESC key during an item drag-move -- see code snippet in prior post), I think we'll be able to fake out subsequent moves by intervening with the use of an override of QGraphicsItem::itemChange(), for the ItemPositionChange case. It will also be important to deal with the other selected QGraphicItems which were involved in the drag-move.

This ESC key behavior might be appropriate as an enhancement to QGraphicsItem drag-moves -- i.e. dropping the grab and restoring the initial position of all selected items involved in the drag-move.