aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/handlers/qquickpinchhandler.cpp
diff options
context:
space:
mode:
authorJan Arve Saether <jan-arve.saether@qt.io>2016-11-18 10:11:58 +0100
committerShawn Rutledge <shawn.rutledge@qt.io>2016-11-20 21:09:40 +0000
commit567811a52ecbd4de312750ba7d7855e560a1d7af (patch)
treecbcd7b209753f77de6f558b12a0f862d16bd1b9b /src/quick/handlers/qquickpinchhandler.cpp
parent542eda976c2767ed6c1eecb4dbcbf838e0ca5a19 (diff)
Remove QQuickMultiPointerHandler::startingCentroid
startingCentroid() used sceneGrabPos() in order to calculate the starting centroid. Unfortunately, the starting centroid should not always be calculated by the touch points initial grab position. Consider the following: 1. Two touch points (P1 and P2) are pressed at position s1 and s2. - Their sceneGrabPos() will return s1 and s1 respectively. - startingCentroid() returns the point between s1 and s2. 2. The two touch points are moved to position m1 and m2. - sceneGrabPos() will still return s1 and s1 - startingCentroid() returns the point between s1 and s2. 3. Touch point P1 is released, and then pressed again. - P1->sceneGrabPos() returns m1 - P2->sceneGrabPos() returns s2 - startingCentroid() returns the point between m1 and s2, which is not what we expect. It is expected that the startingCentroid then would return the point between m1 and m2. Because of this, startingCentroid cannot live up to its promise. Good news is that implementations would just need to query the starting centroid themselves by for instance querying touchPointCentroid() when the handler becomes active. Change-Id: I90fc23f2dd071998efab881cea9ba29b232cf118 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Diffstat (limited to 'src/quick/handlers/qquickpinchhandler.cpp')
0 files changed, 0 insertions, 0 deletions