summaryrefslogtreecommitdiffstats
path: root/examples
diff options
context:
space:
mode:
authorShawn Rutledge <shawn.rutledge@qt.io>2018-07-26 08:14:13 +0200
committerShawn Rutledge <shawn.rutledge@qt.io>2018-07-27 13:24:32 +0000
commitb8fd580cb3453b3850c36765c4b2537538d2f4f8 (patch)
treeca1ae25bf2535a1405ee534ed1fa634ad77b1f13 /examples
parentf2ba3bd9792500b4d3fcfd23b03098a32641ef4f (diff)
TapHandler: emit eventPoint from the tapped signals
Any JS callback using one of these signals probably needs to know which button was tapped. We do not want to require TapHandler.point.pressedButtons to tell a lie (temporarily hold the previous state even though a button was actually released). We could add a releasedButtons property, but it would be a bit weird to have it holding state indefinitely between events. We could add just a button parameter to these signals, which would not be so bad, but emitting the whole eventPoint opens up other possibilities, like doing filtering in JS based on the device. To be able to get the device property of the event in QML, it must not be a const pointer. Q_PROPERTY(const type* ...) is so far unprecedented in Qt Quick; and the device has only const properties anyway. This reverts 8dc02aab72a714b5195ccc641fbfb534c3ae9e98 Task-number: QTBUG-61749 Task-number: QTBUG-64847 Change-Id: I09067498b22cc86e9f68c5ff13d6aa5447faba3d Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Diffstat (limited to 'examples')
0 files changed, 0 insertions, 0 deletions