If exclusiveSignals == NotExclusive (the default), behavior remains as
it was: singleTapped() and doubleTapped() are emitted as the taps occur,
so it's not very useful to react on singleTapped() if you mean to
distinguish these two cases.
If exclusiveSignals == SingleTap, the doubleTapped signal will not be
emitted at all, and therefore singleTapped can be emitted immediately
and unambiguously.
If exclusiveSignals == DoubleTap, the singleTapped signal will not be
emitted at all, and therefore doubleTapped can be emitted immediately
and unambiguously.
If exclusiveSignals == SingleTap | DoubleTap, we must wait
qApp->styleHints()->mouseDoubleClickInterval() milliseconds after a tap
is detected before emitting either signal, so that they are distinct and
can be used to drive behavior that should not occur in other cases.
A triple-tap will not trigger either signal.
[ChangeLog][QtQuick][Event Handlers] TapHandler.exclusiveSignals now
lets you make the singleTapped and doubleTapped signals exclusive.
Task-number: QTBUG-65088
Fixes: QTBUG-107264
Change-Id: Ifb2c4b72759246c64b3bfa2f776c28266806b985
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Multiple TapHandlers must be able to react to multiple touchpoints.
Often when multiple touchpoints are in contact, some of them will be
stationary. In that case TapHandler should not give up its active
state, which is the result of returning false from wantsEventPoint().
This partially reverts commit dcc7367997.
Fixes: QTBUG-76954
Change-Id: I836baf771f09d48be8d032472b0c3143e8f7f723
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
We don't want it to hold its position indefinitely after the button is
released. But in practice, reset() gets called again anyway in
QQuickSinglePointHandler::handlePointerEventImpl(), _after_
handleEventPoint(), which means after tapped() is emitted. Having the
point hold its position that much longer is convenient for applications
and more consistent with the state expressed by the release event.
Also amend the documentation.
Partially reverts 17237efaef
[ChangeLog][Event Handlers][Important Behavior Changes] TapHandler.point now
holds the release position while the tapped() signal is emitted.
Fixes: QTBUG-76871
Task-number: QTBUG-64847
Change-Id: I621a2eba4507a498788e9384344e8b4b7da32403
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
We already emitted grabCanceled() to inform QML callbacks, but we didn't
call reset(). It seems more proper to do everything that would normally
be done when grab is canceled. TapHandler should not give up its passive
grab yet though, because that prevents delivery to any parent Flickable
that might be filtering events. A parent Flickable should be able to
start flicking after the drag threshold is exceeded (it happens to be
exactly when TapHandler gives up).
Fixes: QTBUG-71466
Fixes: QTBUG-71970
Change-Id: Ibba1b0de92cfd88547eeb44edb095d019de76a94
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
... and clean up imports in examples, snippets and tests accordingly.
Change-Id: I5bbe63afd2614cdc2c1ec7d179c9acd6bc03b167
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
This is for the sake of convention. Unfortunately (and the reason
it wasn't done this way at the outset), it may prevent us from ever
having a signal called "pressed" in this handler or its base class.
Change-Id: Iafa117410e0e33562290b87df59bc8c0085c217d
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Shawn Rutledge
Lucie Gérard
Kai Koehne
Jan Arve Saether