| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
This was the intention already in 5.12, but we left it with
Q_AUTOTEST_EXPORT until now. Users should be able to begin experiments
with subclassing handlers, since that is intended to be officially
supported in 5.14 with public headers.
Change-Id: I89471b3ef748936059ed4444eac5348d26a3344b
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enum represents a transient state transition, and only sometimes
corresponds to the current grab state of an event point. For example
after exclusive grab has been canceled, the current state is that
there is no exclusive grab: it doesn't make sense to remember that the
way it got there was by cancellation. There was an idea to add a
grabState property, but not all values would be eligible. An
EventPoint can be exclusively grabbed by one item or handler at a
time, and by multiple passive grabbers at the same time, so even a
Q_FLAG would not fully express all possible states. Besides, there is
already an exclusiveGrabber property, and we could add a
passiveGrabbers list property if we had a real need. So adding a
grabState property seems unlikely, and therefore is not a good enough
reason to keep this enum named as GrabState.
Change-Id: Ie37742b4bd431a7e51910d79a7223fba9a6bd848
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- Constructors should take QQuickItem* not QObject* to be symmetric
with the parentItem() accessor (and other code) which assumes its type
- Use header initialization everywhere possible
- Reorder variables to minimize padding (somewhat)
- Remove empty destructor bodies (the compiler can write them)
- Remove override and virtual from destructors in accordance with
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override
Change-Id: I682a53a803d65e29136bfaec3a5b534e975ecf30
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is for convenience. It's nicer not to need to test tapCount
in JavaScript if you know you want to react on double-click:
onTapped: if (tapCount === 2) doSomething() becomes
onDoubleTapped: doSomething() Neither of these are
guaranteed to be exclusive though: singleTapped occurs first,
then doubleTapped if you tap again quickly, then tapCount
keeps increasing as long as you keep tapping.
Change-Id: I6fff10880831d5be0848b9957141311db8c2c0f0
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
From now on we prefer nullptr instead of 0 to clarify cases where
we are assigning or testing a pointer rather than a numeric zero.
Also, replaced cases where 0 was passed as Qt::KeyboardModifiers
with Qt::NoModifier (clang-tidy replaced them with nullptr, which
waas wrong, so it was just as well to make the tests more readable
rather than to revert those lines).
Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d
Reviewed-by: Simon Hausmann <simon.hausmann@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>
|
| |
|
|
|
|
|
|
|
| |
Renames:
QQuickPointerSingleHandler -> QQuickSinglePointHandler
QQuickMultiPointerHandler -> QQuickMultiPointHandler
Change-Id: I10c54944f85ca7cac374ebc6241d61793e2d38bf
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
| |
The information is already available from the 'point' property of
QQuickPointerSingleHandler
Change-Id: I96bdf2f1d8fbd1de901710a0d12dee5604565756
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
| |
Change-Id: Ib61471a929e387ac64c31d07c9ec5a941cc92d3a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
| |
Change-Id: I17b3865d70bdc07912d7454b459dea40b9c98df0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
onGrabChanged and handleGrab looked redundant. It was also not clear
how important it is for handlers to react to passive ungrabs, overrides
or cancellations. Rather than debating about when to call one of these
and when not to, let's centralize the responsibility in
QQuickEventPoint (because the grabber pointers are stored there, so
it's the ultimate destination of any grab change), and let's notify
all the relevant handlers about all changes, with enough information
that each handler can decide for itself what's important and what
isn't. But so far most handlers don't need to override this virtual.
The base class QQuickPointerHandler takes care of setting the
active property to false, rejecting the eventpoint, and unsetting
keepMouseGrab and keepTouchGrab whenever grab is lost; and emitting
grabChanged or canceled as appropriate to notify any QML code which
needs to know. Subclasses mainly care about the change of active state:
they must initiate active state themselves, and may react when it
reverts to false.
Change-Id: I6c7f29472d12564d74ae091b0c81fa08fe131ce7
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
| |
It enables long-press gestures to have continuous feedback.
Change-Id: Idd0838aff6213ebfc2fce66639bbc932e77208b4
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now it behaved as if this was set to DragThreshold: give up on
the tap as soon as you are clearly dragging rather than tapping.
But that's not what is normally wanted when building a Button control,
for example. So provide 3 options: give up past the drag threshold,
when the pointer goes outside the bounds, or when it's released
outside the bounds. The longPressThreshold also constrains all
three cases: holding (or dragging) for too long will not result
in an immediate cancellation, but it also will not be a tap gesture.
Change-Id: I95aec978e783892b55371391a27642751d91d9ff
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
| |
Add a longPressed signal, emitted when the point is held long enough.
Add the longPressThreshold to control how long that is.
Change-Id: I95a65f1e4c62eb41fb9ea02b14bdc3f16aa72ec2
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
Device-agnostic tap/click detection. Also detect whether the
taps or clicks occur close enough together in both time and space
to be considered part of a multi-tap gesture.
Change-Id: I41a378feea3340b9f0409118273746a289641d6c
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
