aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquickevents.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix memory leak with QQuickEventPointJeremy Powell2019-04-241-22/+16
| | | | | | | | | | | Store PointVelocityData by value in the QMap to avoid leaking memory. This also appears to be slightly faster than heap allocation, with the struct being relatively small (24 or 32 bytes depending on qreal). Fixes: QTBUG-73182 Change-Id: Ibd9374746b76fd5b78c23283d278b6af42907c96 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Don't crash when passive grabber deleted before exclusive gr. releasedShawn Rutledge2019-02-261-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | In this scenario, a DragHandler is inside an Item in a Loader, under a MouseArea, which unloads the loader on press. So on press, the DragHandler acquires a passive grab, then the MouseArea acquires the exclusive grab, then the DragHandler is destroyed along with its parent when the Loader is unloaded. On release, QQuickEventPoint::setGrabberItem(nullptr) was sending an onGrabChanged(passiveGrabber, OverrideGrabPassive, this) notification. That was questionable: the handler was not just then getting its grab overridden, but rather un-overridden, because the exclusive grab was being released. It's also a good idea to check for null pointers, since m_passiveGrabbers is a collection of QPointers already, so we can tell when a passive grabber is deleted dynamically. It can also be reproduced with MultiPointTouchArea just as with MouseArea, so the test is written that way for convenience, because we have tst_multipointtoucharea_interop already. It doesn't really matter which handler has the passive grab, or which item has the exclusive grab that's being relinquished. Fixes: QTBUG-73819 Change-Id: Ic605efa2143a1d849be095dcb88d6c38d7d2ee19 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* TapHander: do not "want" an eventPoint that is outside parent boundsShawn Rutledge2019-01-301-1/+1
| | | | | | | | | | | | | | | | | So far it was checking parentContains() on press, release, or when the gesturePolicy is WithinBounds, but not for each movement when the policy is DragThreshold (the default). This might explain most of the remaining warning noise: "pointId is missing from current event, but was neither canceled nor released" because it was possible for TapHandler to remember wanting a point that it should not have wanted, but without taking any kind of grab, and then complaining when that point was no longer present. Since it did not grab, it did not get the release, unless the release was part of an event containing a point that it DID grab. Fixes: QTBUG-71887 Change-Id: I26ce62279574cf6b0150f24e486f224a604ac6b1 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Merge remote-tracking branch 'origin/5.11' into devUlf Hermann2018-06-251-7/+7
|\ | | | | | | | | | | | | | | | | | | Conflicts: src/plugins/qmltooling/packetprotocol/qpacketprotocol.cpp src/quick/handlers/qquickhandlerpoint.cpp src/quick/handlers/qquicksinglepointhandler.cpp tests/auto/qml/ecmascripttests/test262 Change-Id: I8908ec8c6116ca626fbd269af7625d4c429429ca
| * Doc: Add missing dots (qtdeclarative)Paul Wicking2018-06-191-7/+7
| | | | | | | | | | | | Task-number: QTBUG-68933 Change-Id: Ibb5aa227e82825085e7214e17dcffcb17fd44157 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* | Deliver QNativeGestureEvent via deliverSinglePointEventUntilAcceptedShawn Rutledge2018-06-211-0/+5
| | | | | | | | | | | | | | | | This just simplifies the code a little, and also enables event filtering during delivery to Items. Change-Id: I407dc9a19207f977b574f2a92f5da892e8752987 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Add QQuickPointerScrollEvent as a wrapper for QWheelEventShawn Rutledge2018-06-201-0/+63
| | | | | | | | | | | | | | | | | | We'll use this for delivery of QWheelEvents to both Items and Pointer Handlers. Later we can perhaps use it for QScrollEvent too. Task-number: QTBUG-68119 Change-Id: I04cbbc85fe1a86cf5fd0374d353876f7e6140b70 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Add QQuickSinglePointEvent as intermed. base for QQMouseEvent and othersShawn Rutledge2018-06-201-96/+48
| | | | | | | | | | | | | | | | | | | | | | | | For now we already have QQuickPointerNativeGestureEvent; and in the future, there may be other single-point events such as wheel events. It's handy to reuse the implementations of several virtual functions and the m_point storage. Also format braces more consistently in function implementations. Change-Id: I4b514610b9ed2bd23b7e9a6f1acf826ebd9ebc45 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | fix a crash in QQuickEventPoint::setGrabberPointerHandlerShawn Rutledge2018-05-291-1/+1
|/ | | | | | | | | | If a Pointer Handler is used in an item view delegate, it can hold a passive grab at the time it is destroyed, in which case the QPointer will be set to null. Change-Id: I18d9da36b95a22de327913b3a296bdbea1d7bb1a Reviewed-by: David Edmundson <davidedmundson@kde.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* setGrabberItem: consistently call touchUngrabEvent or mouseUngrabEventShawn Rutledge2018-05-151-4/+6
| | | | | | | | | | | | Calling grabberItem() to get the old grabber must come before setting m_exclusiveGrabber. Then we call oldGrabberItem->touchUngrabEvent() or oldGrabberItem->mouseUngrabEvent() as appropriate. Now the responsibility for this is moved from QQuickItem::grabMouse() to QQuickEventPoint::setGrabberItem() (which it calls). Task-number: QTBUG-65648 Change-Id: Ia6219cb798d7f671ccc4006d51eeb87dbdbda3ef Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Fix build without features.gesturesTasuku Suzuki2018-05-141-1/+10
| | | | | | Change-Id: Id2fb6419be9a35ddaa24106d3022e72070cb908d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* Fix crash when using drag with Drag.AutomaticFriedemann Kleint2018-04-261-3/+10
| | | | | | | | | | QQuickPointerTouchEvent::m_event is 0 when calling QQuickPointerTouchEvent::isPressEvent(). Add a convenience function with a check returning the Qt::TouchPointStates. Task-number: QTBUG-44976 Change-Id: I2433ec3c56adeda2de190ca46aed8413a1357c55 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* touchDevice: don't lose bits from QTouchDevice::capabilitiesShawn Rutledge2018-03-081-2/+1
| | | | | | | | | | | | It was a bug that we made a local QQuickPointerDevice::Capabilities instance and didn't pass it to the QQuickPointerDevice constructor. Further, we've now reserved the entire lower byte for storing QTouchDevice::capabilities, and the upper byte for storing QtQuick- specific capabilities, so we can copy the whole lower byte instead of just the lower nybble. Change-Id: Ia21b6a1503ea870a1e16cebe70a20f4e21903054 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* doc: Correct mostly linking errorsMartin Smith2018-02-231-46/+87
| | | | | | | | | 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>
* doc: Correct several QML property linksMartin Smith2018-02-231-24/+29
| | | | | | | | | | | | This update corrects several QML property links. Currently, the best way to link to a QML property is like this: \l {QtQuick::EventPoint::velocity} {velocity} In other words, use the full path to the property as the link, using '::' as the separator, and use the property name as the label. Enclose both the link and the label in curly braces. Change-Id: I19231403b82d41ad89096dd27787eff57c91b8ae Reviewed-by: Martin Smith <martin.smith@qt.io>
* Add support for getting the flags from the original mouse eventAndy Shaw2018-01-181-0/+12
| | | | | Change-Id: Ifdf0b8cb43b1e88f3931f49ac6ca72019548ddcf Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* a PointerHandler can veto overtaking of grab by an ItemShawn Rutledge2017-11-141-7/+7
| | | | | | | | | | | In order to make sure of it, we have to do the permission check in the legacy call chain too: QQuickFlickable::filterMouseEvent() -> QQuickItem::grabMouse() -> QQuickWindowPrivate::setMouseGrabber() -> QQuickEventPoint::setGrabberItem() -> QQuickPointerHandler::approveGrabTransition() Change-Id: Ice3499bc56e7c89fb43b054ddcd0098fea94ba2a Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* PointerHandler: add grabPermissions, enforce in setExclusiveGrabShawn Rutledge2017-11-141-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QQuickEventPoint: make ungrab/cancel notifications more consistentShawn Rutledge2017-11-141-14/+12
| | | | | | | | | | setGrabberPointerHandler is now implemented more similarly to setGrabberItem. One improvement is that in tests/manual/pointer/pinchDragFlingMPTA.qml the MPTA deactivates when the PinchHandler takes over its touchpoint grabs. Change-Id: I0bd4f143b5f25f1b393839f86c2a7802f1fa1886 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* pre-accept the mouse event before childMouseEventFilter; grab afterShawn Rutledge2017-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In 5.9 a typical filtering sequence would be deliverPressEvent -> deliverMatchingPointsToItem -> QQuickWindow::sendEvent -> sendFilteredMouseEvent -> Test::childMouseEventFilter, let's say it returns true; then because the event is accepted, deliverMatchingPointsToItem grabs the mouse. In 5.10, we rather do deliverPressOrReleaseEvent -> sendFilteredPointerEvent -> sendFilteredPointerEventImpl -> Test::childMouseEventFilter, which returns true; and in this case, setGrabberItem was missing until now. In case of touch rather than mouse, it grabs the touchpoints in this kind of scenario. Also made the failsafe more reliable to ensure that no grabs are retained after release (after seeing that one failing autotest can cause failures in subsequent tests). Done-with: Jan-Arve Sæther Task-number: QTBUG-62631 Task-number: QTBUG-62549 Task-number: QTBUG-62628 Change-Id: I16dafc9aa0de2fc163c524f7f5b109f82d7e84fd Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* docs: EventPoint::timeHeld is a real value, in secondsShawn Rutledge2017-09-291-1/+1
| | | | | Change-Id: I6f581eec8df784878041ccdfc25dd3ebd1a02d70 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* PinchHandler: add native pinch gesture supportShawn Rutledge2017-09-291-2/+116
| | | | | | | | | macOS generates QNativeGestureEvents for 2-finger trackpad zoom and rotation gestures. Now PinchHandler will react to them in the same way that PinchArea does. Change-Id: I4c7dab1d3561d20897e3671f4eb68d01ea06b9bd Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* improve documentation of the PointerHandler base classes and indexShawn Rutledge2017-09-291-4/+359
| | | | | | | also QQuickPointerEvent and QQuickPointerDevice Change-Id: I8bdb7c26cf6a5775a77dbf748c47c170270c5fff Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* rename QQuickEventPoint pos properties to positionShawn Rutledge2017-09-051-6/+6
| | | | | | | | 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>
* Remove isValid from QQuickPointerEventFrederik Gladhorn2017-08-301-4/+1
| | | | | | | | | | | We don't seem to have any use for invalid points, so let's remove the concept. The debug code first checks the valid property, but then unconditionally accesses the event, showing that we never had any invalid event in there in the first place. Change-Id: I5f8aac16c519f06a151198902cc98097eafacaa8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Remove unnecesary if and dead codeJesus Fernandez2017-08-171-20/+17
| | | | | | | | | | | | | | | | | 182648 Dereference before null check There may be a null pointer dereference, or else the comparison against null is unnecessary. In QQuickEventPoint::estimatedVelocity(): All paths that lead to this null pointer comparison already dereference the pointer earlier (CWE-476) Coverity-Id: 182648 Change-Id: Ie8ca1a58b9c11f7c459d719ccd0a3f3fa9eaeea5 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Merge remote-tracking branch 'origin/dev' into wip/pointerhandlerJan Arve Saether2017-07-111-1/+1
|\ | | | | | | | | | | | | | | | | | | | | Conflicts: examples/quick/shared/LauncherList.qml src/quick/items/qquickevents.cpp src/quick/items/qquickevents_p_p.h src/quick/items/qquickwindow.cpp tests/auto/quick/touchmouse/tst_touchmouse.cpp Change-Id: Id692d291455093fc72db61f1b854f3fc9190267b
| * Touch child mouse filtering: pass not grabbed points inside item boundsFrederik Gladhorn2017-05-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | c2ca2cbf04071ffb3aee6af8d5ab9084dfa1c091 started to restrict delivery of items in childMouseEventFilter by checking that we wouldn't deliver completely random points outside the item that were not grabbed by child items. That is generally correct. It did no longer send along touch points that had any other state but pressed but were inside when they had no grabber. That part was wrong, points must be sent along if they are not grabbed and inside the item. Task-number: QTBUG-60368 Change-Id: Ida24f5d2310d3b71db79ae5f95da2c57dcd3f150 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Fix some problems with MouseDblClick handlingJan Arve Saether2017-05-261-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The sequence of events delivered from a double click is: [Press,Release,Press,DblClick,Release] The problem was that a DblClick was delivered just like a press event, so it would clear the passive grabber that was established because of the former Press event. When the Release event then got processed, there was therefore a risk that the Release event was not delivered to the passive grabber. The fix is to not deliver DblClick events at all to handlers, and to not deliver DblClick to items if the former Press event was accepted by a handler. Change-Id: I49c0e32ef4e33f7b6014d35dc065da2527b94779 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Start over with event delivery when touchpoint releases occurShawn Rutledge2017-05-221-7/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | QQuickPointerEvent debug operator: don't crash if original event nullShawn Rutledge2017-05-111-1/+4
| | | | | | | | | | | | | | | | | | QQuickPointerEvent is a wrapper for a QInputEvent. Between event deliveries, the object exists but it doesn't have a current event to which to refer. qDebug() should still work OK anyway in that case. Change-Id: I5aa9584c5d7988bb748befa90785efe8bd24678a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | QQuickPointerEvent debug operator: add timestampShawn Rutledge2017-05-111-1/+3
| | | | | | | | | | | | | | | | It can help to distinguish the time period when we are still delivering the same event. Change-Id: Id738d3e210431f1803cad9ace000c0f702e930fc Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Start over with event delivery when touchpoint presses occurShawn Rutledge2017-04-271-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was part of the intended design for pointer handlers; omitting this feature has until now prevented some opportunities for handoff from one handler to another. Now if PinchHandler has grabbed, pressing one more point will let something else have a chance again, for example. But this is incomplete in that if we release a point, we should do the same thing, actually. Change-Id: I10f567e7e4388bf0caab54c261178f19db20b14a Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | QQuickPointerTouchEvent::reset(): preserve reordered touchpoints betterShawn Rutledge2017-04-201-15/+30
| | | | | | | | | | | | | | | | | | | | | | | | It's not just the grabbers we have to worry about. If touchpoints in one event are in a different order than in the previous one, we need to also preserve anything that was remembered from when that touchpoint was pressed: that is pressTimestamp, scenePressPos, and maybe sceneGrabPos. So now we use a vector of structs for that purpose, which is more extensible and easier to read. Change-Id: Ibf2c0079693ed10988f0066184d53ee9106f2eca Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | QQuickEventPoint: always inform grabberItem on touch grab cancelShawn Rutledge2017-04-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | If we have a TouchCancel event we send it to the Item via sendEvent, so it can be detected in the Item's event() or touchEvent() override. If not, it still needs to be informed that it lost the grab, so call touchUngrabEvent() instead. MultiPointTouchArea for example will stop showing that all its points are pressed, if the grab is stolen by something else. Followup to 59c753bc75c7cfd4068fbbba3c25e1f54c46f4c0 Change-Id: I211c02d51cdde8f8722600cf914485adcc2aa1f3 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Make tst_qquickflickable::nestedSliderUsingTouch passShawn Rutledge2017-04-141-5/+2
| | | | | | | | | | | | | | | | | | | | Revisions to 9b5fc80af28580e9672792dd511d876a93947882 and 781f76176239bfbfe6041f2676e2f2804337d312 are necessary to allow Flickable to steal synth-mouse events from children which accept only touch events. Change-Id: Id779368d7a44c1561da99a9f2c37e8d32278773e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/dev' into wip/pointerhandlerShawn Rutledge2017-04-131-5/+20
|\| | | | | | | Change-Id: Ie2894830470a69827d4ace3d8af9bee971e3fbd4
| * Merge remote-tracking branch 'origin/5.8' into 5.9Liang Qi2017-04-111-1/+16
| |\ | | | | | | | | | Change-Id: Ib3d81ad33a6ba28d891da91271a64d5fcc4874e6
| | * Fix touch event delivery in childMouseEventFilterFrederik Gladhorn2017-03-161-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since moving to pointer events, we would deliver all events inside the filter function. The expected behavior though is that only points that are already grabbed, pressed inside or grabbed by children would be seen by the filter function. This broke using multiple touch aware items at the same time (2 pinch areas for example). Change-Id: I42a430f196ebbcf0a83a6dc8aca319e433ad52ad Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
| * | QQuickEvents: Fix documentation of types for MouseEvent and WheelEvent x/yRobin Burchell2017-03-201-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | These types are qreal, not int. Change-Id: I26569c40825ce098ea095b3d9dc9b84eb3870c02 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | | QQuickPointerTouchEvent::reset: detect the type of exclusive grabberShawn Rutledge2017-03-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Correction to 3b3c8103496f61ebc4b72e73035a4d43fcdd03b0: never set m_exclusiveGrabber without setting m_grabberIsHandler at the same time, otherwise a crash is possible when static_casting to the wrong type and attempting to call methods on the item or handler. Change-Id: I74e015b4fa2edb68cbd5c45bc3aaa6083eec7784 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | | PointerHandlers: fix some grab notification and signal order problemsShawn Rutledge2017-03-081-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The singlePointHandlerProperties manual test showed how this was broken in a couple of ways after 8c659c6c723e4f5f97f46a4555a4765e85c26f1d : - When QQuickPointerTouchEvent::reset() is swapping one point instance for another, and consequently transferring the grabbers from one to another, it should not cause onGrabChanged to occur. Every point update was triggering DragHandler.onGrabChanged. - The order of signal emission is important so that sceneGrabPos will be correct in onGrabChanged. Change-Id: I62a302d6e54126ae10834b6d622e82aa0e434bab Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | | QQuickEventPoint::reset: don't cancel grabsShawn Rutledge2017-03-061-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because touchpoints can be released in a different order than they were pressed, and even the QPA plugins don't guarantee that points in a QTouchEvent will always stay in the same order while they are still pressed, we cannot assume that the order of points will not change every time a touch update occurs. And QQuickPointerTouchEvent has a vector m_touchPoints in which the current points come first: if the first point in that vector is released, it will be reset() to represent a different touchpoint with a different ID. So it follows that QQuickEventPoint::reset doesn't have enough information to decide when a change of pointId means an implicit ungrab; and this code was just a failsafe anyway (thus the qWarning). QQuickPointerTouchEvent::reset() is responsible for identifying which grabs need to be retained in which points from one event to the next, and also currently warns if a point was pressed while still being grabbed from previous interactions. However, a mouse event only has one point, and we rely on QQuickEventPoint to retain the grabbers. Efficiency-wise it doesn't make sense to clear m_exclusiveGrabber and m_passiveGrabbers and then re-populate them each time the mouse moves. Since the risk of reordered points is only for touch events, clearing the grabbers is now done in QQuickEventTouchPoint::reset(). One manifestation of this bug was in multibuttons.qml: sometimes pressing a second button would cause the first button to be released. It turned out to occur whenever the touchpoints got reordered. Change-Id: Ia641f619d763e1a1ea7b59c1e1d08bce9d88e707 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | | notify a PointerHandler when it loses grab due to Item::grabTouchPointsShawn Rutledge2017-03-061-4/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and move more notification responsibility into QQuickEventPoint, thus simplifying QQuickWindowPrivate::grabTouchPoints() which is the implementation behind QQuickItem::grabTouchPoints. It's important for QQuickEventPoint::setGrabberItem to change local state first and then notify, to prevent recursive notify/ungrab loops. MPTA for example does an ungrab when it receives touchUngrabEvent, which then notifies again if the first ungrab was not already fully completed. Change-Id: I6f7b939c8cd76ac5f2d1ddda8b210fa3d31d619a Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | | QQuickWindowPrivate::deliverTouchCancelEvent: deliver to handlers tooShawn Rutledge2017-02-231-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | Now that onGrabChanged() is unified, we have a means to tell the handler when it loses its grab due to a touch event being canceled. Change-Id: Idf3649242233ac7fb8c1fa80ad257ee14b861090 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | | Change QQuickEventPoint::pointId to be plain intJan Arve Saether2017-02-221-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After change 8984c42d1779b13fd29d95274af2d01d32528e52 in qtbase, a QTouchEvent::TouchPoint::id is already guaranteed to be unique across devices. We therefore don't need a larger value space for QQuickEventPoint::pointId, since that value is the same value as we got from the QTouchEvent Change-Id: I044630a812706f3c114bb28cffb29536f9feeeb3 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | | notify a PointerHandler when it loses grab via EventPoint::setGrabberItemShawn Rutledge2017-02-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | If an Item gets exclusive grab, that replaces any existing PointerHandler's exclusive grab, and overrides any passive grabbers as well. Change-Id: I659137a08e7069c8e72ddbb1f27e16d4b19828b9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | | QQuickEventPoint API changes after API reviewJan Arve Saether2017-02-221-19/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * localize -> localizePosition * remove isValid and invalidate * remove isDraggedOverThreshold * remove Q_INVOKABLEs Change-Id: I21f788beb1e86275a9b7a1f1014998b2569001d0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | | unify handler grab state handling into onGrabChangedShawn Rutledge2017-02-211-7/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | clarify further exclusive vs. passive grabsShawn Rutledge2017-02-201-22/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add documentation to the grab-related event and eventpoint methods. Rename "grabber" functions which relate only to the exclusive grab, in cases where it would otherwise be ambiguous. And a few other documentation changes. Change-Id: I1a203c8c06a19d4abdb000f08b387c38341ef476 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-29 19:19:18 +0000