diff options
author | Jan Arve Sæther <jan-arve.saether@qt.io> | 2017-10-19 14:34:47 +0200 |
---|---|---|
committer | Shawn Rutledge <shawn.rutledge@qt.io> | 2017-10-27 14:43:23 +0000 |
commit | 5cb76fb3704947cfc4d575695b137460ecc8bbd9 (patch) | |
tree | ec83080ea86fd407855b459a4b8269ecf22f2e9a /examples/quick/shadereffects/doc/src/shadereffects.qdoc | |
parent | ec596406c03714dbd6865c18c83bf61d615e5791 (diff) |
Fix a bug with TapHandler+DragHandler on top of Flickable
If an item that had a TapHandler and a DragHandler was placed inside a
Flickable it would call sendFilteredPointerEvent() for each of the
handlers, even if they were siblings.
This is not ideal, and because of a mechanism in flickable it even caused
the DragHandler to not drag the item as expected.
This is because of a mechanism in Flickable where the value returned is
actually derived from the previous call to filterMouseEvent() (stored in
member variable stealGrab).
Below are the relevant steps it went through when the mouse drag exceeded
the drag threshold (mouse pointer started on the item):
Precondition: QQuickFlickablePrivate::stealMouse == false
1. Mouse Drag (which exceeded drag threshold)
2. sendFilteredPointerEvent(tapHandler->parentItem()) returns false.
(but since it moved beyond threshold, it would set stealGrab-> true).
3. tapHandler->handlePointerEvent() declined and ungrabbed (due to
DragThreshold gesture policy).
4. sendFilteredPointerEvent(dragHandler->parentItem()) returns true
(because the previous call to sendFilteredPointerEvent() set stealGrab
to true).
As a consequence of (4), dragHandler->handlePointerEvent() was not called,
and the flickable would start to flick instead of the item starting to drag.
Change-Id: Ia99eae91cad0903ebbaedaaafcdf92a25705a922
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Diffstat (limited to 'examples/quick/shadereffects/doc/src/shadereffects.qdoc')
0 files changed, 0 insertions, 0 deletions