DragHandler takes over existing drag gesture which originates outside outside its area

DragHandler takes over a drag which started elsewhere but wasn't handled by anything. This can be easily observed, for example, in KDE/KWin's new Overview effect if you start dragging from an empty space and then cross(intersect) some window along the way. In that case drag centroid is located correctly, but due to the way the effect is implemented, as soon as drag handler activates the window managed by it suddenly jumps by an offset equal to the distance between centroid and the point where mouse touched dragHandler's area.

There's not much we can do to fix it on our side, and anyway DragHandler shouldn't behave this way.

One possible workaround which eventually failed:

1. Set up both TapHandler and DragHandler on the same item.
2. Set DragHandler::enabled initially to false.
3. in TapHandler add signal handler: onPressedChanged: if (pressed) dragHandler.enabled = true
4. Proceed with DragHandler as usual, and don't forget to disable it when its active becomes false again.

It breaks when a user moves move fast in any direction. It seems that in that case TapHandler doesn't even consider the gesture, and so won't activate the drag handler.