aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquickevents_p_p.h
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* 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
| * Fix build without feature.shortcutTasuku Suzuki2017-01-151-0/+2
| | | | | | | | | | Change-Id: Id0ea0037db4cc3878ae2f75109aa3a7daa120189 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | add QQuickEventTouchPoint.ellipseDiameters propertyShawn Rutledge2016-12-301-0/+3
| | | | | | | | | | | | | | | | 201f89f463ae82fe8e9239d7312907062e9a8d15 in qtbase added it to QTouchEvent::TouchPoint. Change-Id: I4e5e08afa0326fd44368777bbd8694d9ef120761 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | add QQuickEventPoint::isDraggedOverThresholdShawn Rutledge2016-12-281-0/+1
| | | | | | | | | | | | | | | | | | | | It will be reusable functionality. OTOH it considers both axes at once, which is not sufficient for DragHandler to use it. If only Qt::XAxis and Qt::YAxis were ORable flags, we could use a flags parameter (with a default) to control which axes to check. Change-Id: I930b39ad35bc669fcc95229b5a8dac7e99c45d78 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Estimate the velocity of a pointJan Arve Saether2016-12-281-0/+4
| | | | | | | | | | | | Change-Id: I45cbfc69a533ea9e295825aef23edc70c88fa2c6 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/dev' into wip/pointerhandlerShawn Rutledge2016-12-281-10/+9
|\| | | | | | | Change-Id: Ib0be3797bfd07589ae177495173dc43c0133ca90
| * change type of QQuickPointerDevice::uniqueId to QPointingDeviceUniqueIdShawn Rutledge2016-12-091-4/+5
| | | | | | | | | | | | | | | | | | | | This will make it easier to change or extend further, in case some future device has some sort of unique serial number which does not fit in a quint64. Task-number: QTBUG-54616 Change-Id: I8f20b13d75b937fce6a66653476d0d25f2abf34b Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
| * rename QPointerUniqueId -> QPointingDeviceUniqueIdShawn Rutledge2016-12-091-5/+4
| | | | | | | | | | | | | | | | | | | | Several people agreed that the name was confusing and that this one is better. Task-number: QTBUG-54616 Change-Id: Ie9d24fc6e233949be36c8b6ee2650080a8a3506e Reviewed-by: Sune Vuorela <sune@vuorela.dk> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Merge branch remote-tracking branch 'origin/dev' into wip/pointerhandlerShawn Rutledge2016-12-201-4/+5
|\| | | | | | | Change-Id: I9ed2e696108f11c9153012fcf092541fd0e0d7c8
| * comment out all uses of QPointerUniqueId temporarilyShawn Rutledge2016-12-041-4/+5
| | | | | | | | | | | | | | | | | | The next step is to rename it, but we do this first to avoid breaking CI while it's renamed in qtbase. Task-number: QTBUG-54616 Change-Id: Iae3a098b9ab5571599af838d19b1869b84b2165f Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | add QQuickPointerHandler::handleGrabCancel; call in setGrabShawn Rutledge2016-10-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | QQuickEventPoint: rename itemGrabber -> grabberItem etc.Shawn Rutledge2016-09-191-4/+4
| | | | | | | | | | | | | | | | 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>
* | QQuickEventPoint: add event propertyShawn Rutledge2016-09-191-0/+1
| | | | | | | | | | | | | | | | When a signal emits a QQuickEventPoint to QML, it's sometimes useful to be able to access properties of the event: buttons, modifiers, device. Change-Id: I6230e31c5abb5e584858d3c0d45cf19199d84bf9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-04 08:31:26 +0000