aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquickevents_p_p.h
Commit message (Collapse)AuthorAgeFilesLines
* Declare the enum so it can be passed to the QML sideAndy Shaw2018-11-301-0/+1
| | | | | | | | | In order for the enum value to be passed to the QML side then it needs to be registered so it can be picked up. This fixes the signals using QQuickEventPoint::GrabTransition, such as PointerHandler's grabChanged. Change-Id: I387930d50f03fee867b3d869618525d44173b538 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Merge remote-tracking branch 'origin/5.11' into 5.12Liang Qi2018-10-291-0/+2
|\ | | | | | | | | | | | | | | | | Conflicts: src/imports/settings/qqmlsettings.cpp src/quick/items/qquickwindow.cpp tools/qmlplugindump/main.cpp Change-Id: I96fedbc773a110374baed79a0b7de92d65df0ed6
| * Warn, don't crash during nested delivery of mouse or touch pressesShawn Rutledge2018-10-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | If during delivery of a mouse press, user code calls qApp->sendEvent() with another mouse press, then when delivery of the nested event is finished, we call QQuickPointerMouseEvent::reset(nullptr). Then when delivery of the original mouse press resumes, crashes are possible because most of the code assumes that QQuickPointerEvent::m_event is not null during delivery. Change-Id: Id65b1f2f64351e40d03bcd4f4d16693d616729da Fixes: QTBUG-70898 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
| * Add some null pointer checks to avoid some rare crashesv5.11.2Jan Arve Sæther2018-09-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The crashes happened because somebody was calling processEvents() from a mouse/touch event handler that was running for a long time. If we called processEvents() from the onPressed handler, and we released the mouse while still not having returned from the onPressed handler, it meant that we were actually delivering the release event before the press event was fully delivered... This should normally not be a problem, but QQuickWindow is reusing the QQuickPointerEvent object for each incoming QEvent, which meant that when we were delivering the release event, it would reuse (and overwrite) the QQuickPointerEvent that the press event handler is still using.... This then caused some assumptions that the code made to be wrong. This only avoids the crashes, and doesn't really fix the "out-of-order" delivery and the state inconsistency that this can lead to (e.g. mouse button states might be still wrong). But on the other hand, it is not the recommended way of making a long-running handler not block the application. The proper way is to create a thread that will run in the background, so that there would be no need to call processEvents() in the event handler. Change-Id: I6fa5d4f5748ef30d082a210f03ef382922bd4b29 Task-number: QTBUG-65454 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
| * Remove const from QQuickPointerEvent::device propertyShawn Rutledge2018-07-271-1/+1
| | | | | | | | | | | | | | | | | | A property never has const pointer as its type. Getting this wrong also causes problems with the QML type registration not matching the actual type. Task-number: QTBUG-61749 Change-Id: Ic3c47499cc4dff6df0beecf5b1413c76509ca6f5 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Remove redundant Q_ENUM declarations in QQuickEventPointShawn Rutledge2018-09-281-3/+0
| | | | | | | | | | | | Task-number: QTBUG-70374 Change-Id: Ic382bef1f6155ecd4d4b0a5a4e7b28b3dcb257ff Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Fix revisioning of QQuickMouseEvent::flagsKai Koehne2018-09-011-1/+1
| | | | | | | | | | Change-Id: If8f8a2f889eba1287664988519a68ee9acf259c6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Rename QQEventPoint::GrabState to GrabTransitionShawn Rutledge2018-08-311-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Fix property declarationsSimon Hausmann2018-08-201-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | It does not make sense to declare a property that has a setter and mark it as constant. Moc also complains about it and notes how the constant attribute is ignored. Therefore we might as well remove it from the declaration. Amends a9b9875acc6155f85558bb27cdb75f2dda5e2b66 Change-Id: Ib78d6e9c5e3415bc2a3dc26477d1d2a4e5b4dcfe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Mark non-notifying properties in event types CONSTANTShawn Rutledge2018-08-061-41/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Event objects are valid only within the context of a JS callback that receives the object as a signal parameter, and the object will not change during the runtime of that callback. It's not true that the properties will never change, because event objects are pooled and reused; but the QML is not allowed to keep a reference to an event, so the property changes during this reuse are not meant to be seen. QQuickMouseEvent is similar, and its properties were already marked CONSTANT. Change-Id: I4985e4a27bf192779629311eb8c6c1f63d22df3e Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | TapHandler: emit eventPoint from the tapped signalsShawn Rutledge2018-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Deliver QNativeGestureEvent via deliverSinglePointEventUntilAcceptedShawn Rutledge2018-06-211-0/+1
| | | | | | | | | | | | | | | | 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/+47
| | | | | | | | | | | | | | | | | | 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-28/+26
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | QQuickPointerEvent: guard all access to m_eventShawn Rutledge2018-05-291-3/+3
|/ | | | | | | | | | | QQuickWindowPrivate::pointerEventInstance(device, eventType) returns a pointer event which is not based on a QEvent: m_event will be null. This is useful for delivering hover events, but the qDebug operator<< crashes when it tries to print the timestamp, if we don't check for null m_event. Change-Id: Id3a93a1ffcae78cbf287f724da9c012a6b546b0b Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix build without features.gesturesTasuku Suzuki2018-05-141-0/+8
| | | | | | 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-0/+2
| | | | | | | | | | 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>
* QQuickWindow: skip mouse synthesis for touch events from trackpadsShawn Rutledge2018-03-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | A trackpad is primarily a mouse-emulating device, which can also recognize gestures, and furthermore can send raw touches iff it is asked to. So, every touch event from a trackpad is likely to be followed by a mouse or gesture event (especially when the MouseEmulation capability confirms that it is able to do that). Therefore mouse event synthesis is redundant. In this bug scenario, MultiPointTouchArea enables touch events within its rectangular bounds. A Flickable is on top. As you flick with two fingers on the trackpad, macOS sends touch events with two touch points (because MPTA enabled touch events) and also a series of QWheelEvents as it recognizes the flick gesture. The Flickable receives mouse events sythesized from one touch point, and reacts as if you were dragging with one finger on a touchscreen, while it simultaneously also reacts to the QWheelEvents. Meanwhile the remaining touchpoint falls through to the MPTA underneath; so the user ends up interacting with both at the same time and making the Flickable jump around besides. This patch just fixes the jumpiness in Flickable: it will no longer receive the synth-mouse events, so it will not be dragged, and will react only to the wheel events. But MPTA still gets the touches. Task-number: QTBUG-66329 Change-Id: I6f535a2c9e47bcb284eaf9ae1fdaa39f8b510af9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* allow DeviceType and PointerType enums 16 bits each; bit packingShawn Rutledge2018-03-021-11/+13
| | | | | | | | | | | | Now in QQuickPointerDevice, the types, flags and capabilities take up 64 bits together, and we reserve enough bits to add more types later. In C++11 enums can be strongly typed by "inheriting" an integer type, so we do that. They are signed because button count and maximum touch points are signed, and because MS compilers do that by default with enums. Change-Id: I45f27bcceeef275cbee256472b35f78fbdeeaad6 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* use the override keyword consistently and correctly (clang-tidy)Shawn Rutledge2018-02-271-2/+2
| | | | | Change-Id: If9e28d143f8cba3df3c757476b4f2265e2eb8b2a Reviewed-by: Johan Helsing <johan.helsing@qt.io>
* init variables where they are declared when possible (clang-tidy)Shawn Rutledge2018-02-261-23/+18
| | | | | | | | clang-tidy -p compile_commands.json $file -checks='-*,modernize-use-default-member-init,readability-redundant-member-init' -config='{CheckOptions: [{key: modernize-use-default-member-init.UseAssignment, value: "1"}]}' -header-filter='qtdeclarative' -fix Change-Id: I705f3235ff129ba68b0d8dad54a083e29fcead5f Reviewed-by: Johan Helsing <johan.helsing@qt.io>
* use nullptr consistently (clang-tidy)Shawn Rutledge2018-02-261-3/+3
| | | | | | | | | | | | | 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>
* Add support for getting the flags from the original mouse eventAndy Shaw2018-01-181-2/+7
| | | | | Change-Id: Ifdf0b8cb43b1e88f3931f49ac6ca72019548ddcf Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Remove deprecated grabber()Jan Arve Sæther2017-11-081-1/+0
| | | | | | | We already have grabberItem() that serves the same purpose Change-Id: I137ebab8ecc2c3924e55015e28735eefc79c2ae8 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* PinchHandler: add native pinch gesture supportShawn Rutledge2017-09-291-1/+40
| | | | | | | | | 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-1/+0
| | | | | | | 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-9/+9
| | | | | | | | 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-1/+0
| | | | | | | | | | | 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>
* Do not break qtlocation when integratingJan Arve Saether2017-07-131-0/+1
| | | | | | | | Once pointerhandlers are merged it should be fixed in qtlocation, and then this should be removed. Change-Id: I8b6364fff762417ac45ea76bfe1c06836c7fdf15 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Merge remote-tracking branch 'origin/dev' into wip/pointerhandlerJan Arve Saether2017-07-111-18/+8
|\ | | | | | | | | | | | | | | | | | | | | 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
| * Revert "Temporarily restore QQuickPointerDevice::pointerEvent() accessor"v5.9.0-rc2v5.9.0-rc1v5.9.0Shawn Rutledge2017-05-201-7/+0
| | | | | | | | | | | | | | | | | | | | This reverts commit ee6b07b3ce8ba80632868181d45d96253acb1064. This is to be integrated after the qtlocation change to remove the dependency on this private function. Task-number: QTBUG-57253 Change-Id: I756681fb2595d1326b7e5206bac57ccc318c0a46 Reviewed-by: Liang Qi <liang.qi@qt.io>
| * Temporarily restore QQuickPointerDevice::pointerEvent() accessorShawn Rutledge2017-05-121-0/+7
| | | | | | | | | | | | | | | | | | This can be reverted as soon as the relevant qtlocation change is integrated. Task-number: QTBUG-57253 Change-Id: I72b71f61ba8fe421ac57c963801176098fe9f11c Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
| * Move pointerEvent instance to QQuickWindowJan Arve Saether2017-05-101-18/+7
| | | | | | | | | | | | | | | | | | | | | | | | With two or more windows, if events are being delivered to each, the grabbers can be different in each. We need unique instances of the QQuickPointerEvent objects for each window to avoid losing the grab state in the parent window while delivering a synthesized event to a subwindow, for example. Change-Id: I51da1212d573853969e32ad78f5b219d979a8a5c Task-number: QTBUG-57253 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Fix some problems with MouseDblClick handlingJan Arve Saether2017-05-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Change enum values to not start from 0Jan Arve Saether2017-05-221-7/+7
| | | | | | | | | | | | | | And allow potential combination of passive and exclusive grabbers Change-Id: I0bd2d6863305c3db7c91b064c0a58cd5e167470e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Start over with event delivery when touchpoint releases occurShawn Rutledge2017-05-221-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | QQuickPointerTouchEvent::reset(): preserve reordered touchpoints betterShawn Rutledge2017-04-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | PointerHandlers: fix some grab notification and signal order problemsShawn Rutledge2017-03-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Property velocity was double definedJan Arve Saether2017-02-241-1/+0
| | | | | | | | | | Change-Id: I7de8e58c6ea5e6ba9ddefcf6018ae180880f6cb5 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | QQuickWindowPrivate::deliverTouchCancelEvent: deliver to handlers tooShawn Rutledge2017-02-231-0/+5
| | | | | | | | | | | | | | | | 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-7/+7
| | | | | | | | | | | | | | | | | | | | | | 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>
* | QQuickEventPoint API changes after API reviewJan Arve Saether2017-02-221-8/+3
| | | | | | | | | | | | | | | | | | | | * 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-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-11/+11
| | | | | | | | | | | | | | | | | | | | 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>
* | QQuickWindow: remove sendFilteredTouchEventShawn Rutledge2017-02-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The functionality is now completely assimilated into sendFilteredPointerEvent. Flickable can now steal the touch grab from a TapHandler child, for example: the TapHandler grabbed the eventpoint, whereas QQuickFlickable::childMouseEventFilter() was given a synthetic mouse event derived from the touchpoint which the eventpoint represented, and we fully follow through the consequences of that. If an Item filters a press event, avoid doing normal delivery to that same Item again. Change-Id: Icd9c88ab752f2b728f7d612504013c6dc72ff9fe Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | start making explicit exclusive or passive grabsShawn Rutledge2017-02-101-4/+11
| | | | | | | | | | Change-Id: I4a6e3c72d69e893fec2e39f4faab24af6d00c7e0 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | QQuickWindow: use QVector eventDeliveryTargets to avoid repeated deliveryShawn Rutledge2017-02-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If no handler or item accepts a newly-pressed point, the event will be re-delivered in deliverTouchEvent(). It doesn't make sense to re-deliver to the same handlers though. A temporary QSet isn't cheap to create, whereas it seems we will need to keep track of handlers which have already been visited, in order to avoid visiting passively-grabbing handlers multiple times. Since both a QVector and a QSet are heap-allocated, and we expect to have a limited quantity of handlers grabbing at one time, a retained QVector (cleared between events) seems to be the cheapest data structure. Change-Id: I831e9a2576b2fcb9095e065795f2baff58115a49 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | QQuickWindow: deliver updates to handlers even if they don't grabShawn Rutledge2017-02-021-0/+6
| | | | | | | | | | | | | | | | | | | | The "weak grab" concept depends on this. First we deliver to grabbers, then we deliver to non-grabbing handlers (but not to non-grabbing items). Avoid re-delivering to grabbing handlers which already received the same event. Change-Id: If51e1cd9372e3bed1daea3758e9ef8e37c0ba5e3 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Merge remote-tracking branch 'origin/dev' into wip/pointerhandlerShawn Rutledge2017-01-261-0/+2
|\| | | | | | | Change-Id: I7962fd2282792c43af69784c8e98fb050fd928a7
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-07 13:53:13 +0000