| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
- Remove links to modules and examples that are not part of Qt 6.
- Remove links to entities marked as \internal
- Add missing enum value and QML property docs where it's trivial
to do so.
Task-number: QTBUG-88156
Change-Id: I10a1c7bcc5fe0e2354ea69eaf24930362edb7415
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
|
|
|
|
|
| |
Change-Id: I0c5697e9df4dc01aeedf427aab723c306e19338d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QEventPoint does not have an accessor to get the QPointerEvent that it
came from, because that's inconsistent with the idea that QPointerEvent
instances are temporary, stack-allocated and movable (the pointer would
often be wrong or null, therefore could not be relied upon).
So most functions that worked directly with QQuickEventPoint before
(which fortunately are still private API) now need to receive the
QPointerEvent too, which we choose to pass by pointer. QEventPoint is
always passed by reference (const where possible) to be consistent with
functions in QPointerEvent that take QEventPoint by reference.
QEventPoint::velocity() should be always in scene coordinates now, which
saves us the trouble of transforming it to each item's coordinate system
during delivery, but means that it will need to be done in handlers or
applications sometimes. If we were going to transform it, it would be
important to also store the sceneVelocity separately in QEventPoint
so that the transformation could be done repeatedly for different items.
Task-number: QTBUG-72173
Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
| |
This is required to remove the ; from the macro with Qt 6.
Task-number: QTBUG-82978
Change-Id: Iead53d18fd790fb2d870d80ef2db79666f0d2392
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...and generally deal with changes immediately required after adding
QInputDevice and QPointingDevice.
Also fixed a few usages of deprecated accessors that weren't taken
care of in 212c2bffbb041aee0e3c9a7f0551ef151ed2d3ad.
Task-number: QTBUG-46412
Task-number: QTBUG-69433
Task-number: QTBUG-72167
Change-Id: I93a2643162878afa216556f10808fd92e0b20071
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, QQuickItemPrivate::setHasCursorInChild() was unable to check
the QQuickItemPrivate::hasCursor variable, because the function
argument hasCursor was shadowing that, even though the comment
"nope! sorry, I have a cursor myself" hints that the intention
was to check that. So this change exposed a problem there, and
we have to fix that too, in order to keep the tst_qquickwindow::cursor()
test passing.
[ChangeLog][Event Handlers] Pointer Handlers now have a cursorShape
property to set the cursor when the handler is active and the mouse is
hovering, and restore to the previous cursor when the mouse leaves.
Fixes: QTBUG-68073
Change-Id: Ib5c66bd59c4691c4210ee5465e1c95e7bdcf5ae1
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
| |
Fixes the QTextStream usages.
Change-Id: I0c009a82fb644a9f3c3d42ec410d18b680977f23
(cherry picked from commit 1c5c5f7aadc2dcc73a21eeb818e95c4e1b7de70f)
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
src/qml/common/qv4compileddata_p.h
Change-Id: I1150c8cd0161f0e22137d383013751394ae64e18
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The scenario:
- mouse press: MouseArea grabs; DragHandler gets a passive grab
- drag a little: DragHandler's drag threshold is exceeded
- drag some more: DragHandler tries to take the exclusive grab
This grab takeover succeeded before, because although MA has
keepMouseGrab(), the event being delivered is a touch event,
and MA does not have keepTouchGrab().
If this happens while QQuickWindowPrivate::touchMouseId is the
same touchpoint that the DragHandler is trying to grab, it should
not succeed, because we honor the keepMouseGrab() flag. I.e.
keepMouseGrab() implies keepTouchGrab() whenever the touchpoint
under consideration is currently the touch-mouse.
On the other hand, if a DragHandler is used on some item inside
a Flickable: on press, the Flickable grabs right away (it has a
bad case of FOMO), but the DragHandler just gets a passive grab.
When the drag threshold is exceeded, DragHandler must be able to
steal the grab from Flickable, because Flickable was just being too
aggressive. So now we have the rule that if the Item it wants to steal
the grab from is a parent of the type that filters all events,
it's OK to ignore the keepMouseGrab() flag and steal anyway
(as it did before this patch).
Fixes: QTBUG-79163
Change-Id: I2b3f175bea867cb737357857657653b0a7b83995
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need drag threshold to be adjustable on each handler instance instead
of relying only on the system default drag threshold. For example in
some use cases DragHandler needs to work with a threshold of 0 or 1 to
start dragging as soon as the point is pressed or as soon as the point
is moved, with no "jump", to enable fine adjustment of a value on some
control such as a Slider.
This involves moving the dragOverThreshold() functions that handlers are
using from QQuickWindowPrivate to QQuickPointerHandlerPrivate, so that
they can use the adjustable threshold value.
Task-number: QTBUG-68075
Change-Id: Ie720cbbf9f30abb40d1731d92f8e7f1e6534eeb5
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
* grabPermissions is a flags property, not bool.
* Add a list of the possible grabPermissions values.
* Fix two other places where \qmlproperty enum was used
instead of enumeration.
* acceptedButtons, acceptedDevices, acceptedModifiers and
acceptedPointerTypes are flags properties, not plain int.
Change-Id: I6f49dcc1e1762e913e4989b208380d64899630a6
Reviewed-by: Jan Arve Sæther <jan-arve.saether@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We always intended to "start over" with event delivery when the number
of touchpoints changes. Change 48011c2dfeb83b4fe717034d4b3c353714fead48
began this process, but in addition to QQuickWindow delivering the
event to all items and their handlers in reverse paint order, ignoring
existing grabs, the handlers themselves have responsibility to act
as if it was an initial press whenever the number of relevant
touchpoints changes; and because QQuickWindow starts over, handlers do
not need to rely on passive grabs to retain interest in one point at
the time when a transition to a different number of points occurs.
For example, DragHandler by default handles just one point, so if you
press one point such that it takes a passive grab and adds that point
to m_currentPoints, then you press a second finger within the bounds
of the same parentItem, the DragHandler should not go on "wanting" the
first point anymore, because a two-finger gesture is different, and
not suitable for the DragHandler unless its maximumPointCount >= 2.
Even if the second point is released, QQuickWindow will "start over"
with delivery, so a multi-point handler does not need to rely on
retaining a passive grab to handle the transition from two points back
to one again.
This also helps enable smoother transitions between different
gestures: e.g. in the map.qml manual test, you can drag one finger and
transition from dragging to pinching and back while the second finger
is pressed, dragged and released.
Change-Id: Id9b8f30029ed1ff9fd2d64a5e413a47055622083
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At QtCS 2018 we decided to rename Pointer Handlers to Input Handlers
and include the Keys attached property as part of this set (since we
plan to have attached-property pointer handlers too, eventually).
It's no longer a module, it's included in Qt Quick 2.12. We need to
start promoting Input Handlers and reducing the visibility of legacy
stuff like MouseArea and MultiPointTouchArea (in the hope of being
able to deprecate them eventually).
Task-number: QTBUG-66651
Change-Id: I801351ac2531191cbb1faac9318441c67a109af6
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
|
|
|
|
|
|
|
|
|
| |
Followup to da722fb448f06cf43780e6f857a1ccd9f07176d6
Task-number: QTBUG-68077
Change-Id: I93322949018091e453297164ef1838619d19ee57
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Reviewed-by: Martin Smith <martin.smith@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a documentation change to alleviate some confusion that we've
seen during the Tech Preview period.
It doesn't make sense to actually rename the base class though, because
it is intended to handle QQuickPointerEvents, not QEvents. The reason
for that is that refactoring the QEvent hierarchy has to wait until
Qt 6. So maybe in Qt 6 we can remove QQuickPointerEvent and have
a QQuickInputHandler base class which handles QInputEvents; but for
now, this conceptual renaming seems about as far as we can go.
Task-number: QTBUG-66651
Change-Id: I84a41dc282c480d08f4d4a0d9a857e37e074aa7a
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
|
|
|
|
|
|
|
| |
It was too hard to debug behavior in this test.
Change-Id: Iaec9534cca17bdd90b94cfa8fa8b21b7026839ae
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's not just useful for PinchHandler: TapHandler has a good use for it
too. But unfortunately if the handler's parent Item has a custom mask,
we don't have a way to augment the mask with a margin; so if margin is
set, we assume the bounds are rectangular.
QQuickMultiPointHandler::eligiblePoints() now calls wantsEventPoint()
rather than bounds-checking the point directly: this adds flexibility,
potentially allowing an override in subclasses, if we need it later.
Task-number: QTBUG-68077
Change-Id: I65c95f00c532044a5862654e58c9c5f8c973df81
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Detect whether the handler's parent contains the mouse, while the
point property tracks the event point (position etc.)
Task-number: QTBUG-68072
Change-Id: Ica99332596eab3e344852a11f1ceb7aaf6348c86
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
| |
To make grabChanged signal useful, it's necessary to know whether the
Pointer Handler has acquired or lost the grab. This patch fixes that.
Task-number: QTBUG-68074
Change-Id: I29398d2bb5b27b8541197f23c3043ee86cad7c76
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
| |
We want to be able to call it from the upcoming
QQuickItemPrivate::anyPointerHandlerWants function.
Change-Id: I15ef60303fa56f43e66b16c8dd0f4102070536d0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
>>> Non-static class member "reserved" is not initialized in this constructor nor in any functions that it calls.
Coverity-Id: 190209
Change-Id: Ia1c07ff16b2015d99ab15f387ac6cc687703fcbb
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
| |
Follow the usual pattern in preparation for making this class public.
Change-Id: I8330cdda27e131a5f93723d4cf4c53a9f7630434
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
| |
They are public in QQmlParserStatus but don't need to be public here.
Also de-inline the default implementations, because this class will
be public C++ API eventually.
Change-Id: Ic7dfbec853e3d20f45b361401f710dedb5eae416
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
| |
This update corrects many qdoc warnings, mostly of the "Can't link to..."
variety, but there were also a few qdoc comments added. As of this update,
the qdoc warning count is 46 in QtDeclarative.
Change-Id: Icf2d34c7ce7010ebfd9b474feacfe8af42f3fd5f
Reviewed-by: Martin Smith <martin.smith@qt.io>
|
|
|
|
|
|
|
|
| |
To be overridden in handlers which need to know when this happens,
to avoid connecting to the targetChanged() signal.
Change-Id: I51432b69d05fd541eb62e0cd01f4019e336816ac
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As soon as we enable the concept that PointerHandlers can use passive
grabs to lurk, monitor all movements, and then steal the passive grab,
they can fight over the grab. For example if there are two items with
PinchHandlers, and two or more touches occur within bounds for both,
then each update event can cause the other PinchHandler to steal the
grabs and become active.
So we replace stealing with negotiation: the handler which wants to
take over the grab checks its own flags to see whether that's allowed,
and the handler which is about to lose its grab also has the right
to approve or deny the takeover (just as QQuickItem has had
keepMouseGrab and keepTouchGrab for a long time.) Additionally,
if one handler wants to cancel another handler's grab without
taking over (simply set the grabber to null), it must be approved.
A single-point handler can simply call setExclusiveGrab, with the
expectation that permission may be granted or denied. A multi-point
handler only wants to grab all points if grabbing all of them will
be allowed, otherwise grab none; so it calls canGrab on each point
to check beforehand. Thus, when two handlers are competing for the
same grabs, one or both can be prevented from stealing from each other,
or from Handlers in general, or from Items, or some combination.
Change-Id: I5c733b2b8995ce686da0be42244394eeee82a268
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
The indicated dead code may have performed some action; that action will never occur.
In QQuickPointerHandler::onGrabChanged(QQuickPointerHandler *, QQuickEventPoint::GrabState, QQuickEventPoint *): Code can never be reached because of a logical contradiction
Coverity-Id: 182646
Change-Id: Ic3ccffddf3052337d22d5dd7fabb8bfa7af35dbe
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
|
|
|
|
|
|
|
| |
also QQuickPointerEvent and QQuickPointerDevice
Change-Id: I8bdb7c26cf6a5775a77dbf748c47c170270c5fff
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
| |
For consistency we always spell it out, although it does make some
of these properties inconveniently verbose.
Change-Id: I64a08c3aa261c0ab89e09472dd47510abafbf7ca
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qquickpinchhandler.cpp:138: warning: Missing property type for QQuickPinchHandler::minimumX
qquickpinchhandler.cpp:151: warning: Missing property type for QQuickPinchHandler::maximumX
qquickpinchhandler.cpp:164: warning: Missing property type for QQuickPinchHandler::minimumY
qquickpinchhandler.cpp:177: warning: Missing property type for QQuickPinchHandler::maximumY
qquickpinchhandler.cpp:194: warning: Missing property type for QQuickPinchHandler::minimumTouchPoints
qquickpinchhandler.cpp:198: warning: Missing property type for QQuickPinchHandler::active
qquickpointerdevicehandler.cpp:107: warning: Missing property type for QQuickPointerDeviceHandler::acceptedModifiers
qquickpointerhandler.cpp:47: warning: C++ class QQuickPointerHandler not found: \instantiates QQuickPointerHandler
qquickpointerhandler.cpp:176: warning: Missing property type for QQuickPointerHandler::enabled
qquickpointerhandler.cpp:255: warning: Missing property type for QQuickPointerHandler::parent
qquicktaphandler.cpp:175: warning: Missing property type for longPressThreshold
qquicktaphandler.cpp:235: warning: Missing property type for gesturePolicy
qquicktaphandler.cpp:252: warning: Missing property type for pressed
qquicktaphandler.cpp:329: warning: Missing '\endqml'
qquicktaphandler.cpp:340: warning: Missing property type for tapCount
qquicktaphandler.cpp:353: warning: Missing property type for timeHeld
Change-Id: I8a5bd0ec7c5603573f39f5b5f1f24d5735ba98dd
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new rule is that when the number of touchpoints changes, we start
over with event delivery as if the touch had just begun, to give more
opportunities to hand off processing from one item or handler to
another. And MultiPointTouchArea can now handle the handoff:
for example in tests/manual/pointer/pinchDragFlingMPTA.qml when the
user is pressing three fingers, the PinchHandler is active; when the
user then lifts one finger, the MPTA can resume handling the two
remaining touchpoints as if they were just pressed.
The change in QQuickMultiPointerHandler::wantsPointerEvent is both
a behavior change and an optimization: released points aren't eligible;
but if some points are released, then pressed, updated and stationary
points are all eligible. And, figure this out without looping over the
points twice.
Change-Id: I26b7593de8e72b471adfec4a4482dd87a8288442
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is required to keep the tst_flickableinterop touchDragSlider test
passing after the change to TapHandler to never give up passive grab.
And QQuickEventPoint::setGrabberPointerHandler(nullptr, true)
will just go ahead and allow TapHandler to cancel the grab which
the DragHandler currently has at that time, when you have pressed
the TapHandler but started dragging so that the drag threshold is
exceeded. (Perhaps this points to an API problem.) For now, we at
least can enforce the rule in QQuickPointerHandler::setExclusiveGrab
that if grab is false, it won't nullify the grab of a different handler.
Change-Id: I7c93188cfdce51b3b5a17c13e5efc7fcbd123d4b
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
| |
and remove the similar "delivering to" log from QQuickItem.
It's more useful to know whether delivery will continue rather than simply
that we made an attempt.
Change-Id: I58c37fb50d4d0c99ef6aa68662ab304194b6d128
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
In autotests, stationary points normally have invalid position.
A TapHandler does not need to react to them anyway.
But we must also avoid having a grab cancelation due to a stationary
point, and that applies to all PointerHandlers in general.
Change-Id: I99493ad7d859e0c4ef155afc699aa34f28ffdbc7
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
That means the PinchHandler for example will require exactly
requiredPointCount touchpoints. If it was satisfied, then one finger
is released, it must give up its grabs so that another PointerHandler
has a chance to take over.
Change-Id: I28e32d6d3f255c7de8023f054dc480528bb14852
Reviewed-by: Jan Arve Sæther <jan-arve.saether@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whenever the DragHandler gets an exclusive grab, it needs to prevent
a parent Flickable (for example) from taking over that grab. Since
it waits until the drag threshold is exceeded in an allowed dragging
direction, this does not prevent the Flickable from being draggable
in the other direction.
We restore the state of keepTouchGrab and keepMouseGrab when ungrabbing.
Change-Id: Id9d456c99322e0cb6996d1f690b38fcd6becc6f9
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
| |
Change-Id: I45df7abdbd91e068a69101ed27e2ec44272e3899
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
| |
Change-Id: I4a6e3c72d69e893fec2e39f4faab24af6d00c7e0
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
| |
When requested to grab, it was emitting this signal and calling
onGrabChanged every time.
Change-Id: I32ce80e4d6ff8b8e950b5d2f977bd737e31b8ac8
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a QQuickPointerSingleHandler grabs a point, it's definitely in the
active state: doing something with the point. (The converse is not
always true though: e.g. TapHandler can sometimes detect a tap without
ever grabbing.)
In DragHandler, the "dragging" property means the same as "active":
we always grab when dragging, to be sure to get the updates. So the
"dragging" property is removed because it's redundant.
In QQuickPointerHandler we don't say that "wanting" an event is the
same as being active, because 1) it won't necessarily grab right away
and 2) every handler which was active should "want" the release event,
yet it needs to setActive(false) as soon as it's done processing it.
Change-Id: Ie010db54714a7914109da6469e79865f9a0a18e4
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
To summarize: A pointer handler always gets its pointer events from its
parent item. It applies its effect (drag, pinch, ...) on the item
referenced to by the target property. By default, target refers to the
parent, but that is not always the case. In addition to this we also
have to handle the case when the target is null
Change-Id: If62108abf0aeb713906bf88472ad9a32a74efff6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
| |
Change-Id: I34db4be279a68a7bf66adb604b12f8aff3c1bac4
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
Some handlers will need to react to gaining or losing a grab, in both
C++ and QML.
Change-Id: I25b94800e3eaeabb0782315c679813ec735d4d51
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and override it in PinchHandler. Many handlers will need to do
something in response to change in active state, so calling a virtual
when the state changes and overriding it in subclasses is more
efficient than for subclasses to connect to the activeChanged signal.
This also helps us control the signal emit order: the subclass can
deal with any consequences (such as changing its own properties) before
activeChanged is emitted.
Change-Id: I6d05643e8facfd1941aa9152de6865932edb1b3a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
The parent is the Item in which the handler is instantiated.
It cannot (so far) be reassigned to a different item, so this is not
the same as QQuickItem's parent property: it's rather a convenience
to get the QObject parent and cast it.
Change-Id: Ib352213589532f45f104c8d83f04fd14107a4a20
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only one handler can be the grabber at one time, so we need to ensure
that we notify the others when they lose the grab. Also handle this
in QQuickPointerSingleHandler: forget m_currentPointId, so that
wantsPointerEvent will not continue to "want" the same ID.
Also add the canceled(QQuickEventPoint *point) signal, which
is one of the four possible "state signals" (press, update, release,
cancel) but which we didn't commit to adding yet.
Change-Id: I46256acb75ece863d84e812af2d30cb0b12e3c1f
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
|
|
|
|
|
|
|
|
| |
QQuickWindow::mouseGrabberItem already existed, so we have a precedent
for "specific thing which grabs" to come after the word Grabber.
Change-Id: I65847ee0a005fac9b6292b9b91bb16f5f180e9bb
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
|