aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/pointerhandlers
Commit message (Collapse)AuthorAgeFilesLines
* Stabilize tst_QQuickWheelHandler's activeChangedSpy checksShawn Rutledge2019-04-272-3/+5
| | | | | Change-Id: I9fa36d12347f0311728dc14ab4b8405bf0550505 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add WheelHandlerShawn Rutledge2019-04-275-0/+457
| | | | | | | | | | | | | It can be used to change any qreal property of its target Item in response to wheel rotation, or it can be used in other ways that involve bindings but without a target item. [ChangeLog][QtQuick][Event Handlers] Added WheelHandler, which handles mouse wheel rotation by modifying arbitrary Item properties. Fixes: QTBUG-68119 Change-Id: I247e2325ee993cc1b91a47fbd6c4ba0ffde7ad49 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-04-191-0/+2
|\ | | | | | | Change-Id: I9ef4be23bfe35aa48d4c65d4159e72c527943845
| * Blacklist ...::touchDragFlickableBehindButton() on mingwUlf Hermann2019-04-171-0/+2
| | | | | | | | | | | | Task-number: QTBUG-75224 Change-Id: Ic7daefa2f0422a0b1cfa112fd5412cafffb2a9ed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13v5.13.0-beta2Qt Forward Merge Bot2019-04-092-0/+69
|\| | | | | | | Change-Id: I68211a7d4568a1c31c6a124fe6777709c53736a5
| * If DragHandler is dragged within its margin, don't jumpShawn Rutledge2019-04-052-0/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Not being pressed inside the target is a necessary but not sufficient reason to reset m_pressTargetPos to the center of the target. The intention was rather to make the target jump into position when the parent was a different item: e.g. if a Slider has a DragHandler whose target is the slider's knob, you can start dragging anywhere on the whole Slider but you want the knob to jump to the cursor position when the drag begins. While we're at it, both branches of the if in onGrabChanged() are checking that target() isn't null, so we can move that check out. Fixes: QTBUG-74966 Change-Id: I05be11d27422b070d941b9e43d4e1157e071c3a5 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Tests: Fix warnings about ignoring return value of ↵Friedemann Kleint2019-04-081-1/+1
|/ | | | | | | | | | | | | | QTest::qWaitForWindowExposed() Fix warnings like: ../shared/particlestestsshared.h: In function 'QQuickView* createView(const QUrl&, int)': ../shared/particlestestsshared.h:64:33: warning: ignoring return value of 'bool QTest::qWaitForWindowExposed(QWindow*, int)', declared with attribute nodiscard [-Wunused-result] by checking the return and adding some handling. Change-Id: I1390f9738430042fcc45e243567a9d5a4f632a6d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Fix a bug where hover events were not sent if the mouse was never movedJan Arve Sæther2019-03-042-1/+38
| | | | | | | | | | | | | This happened if the "real mouse" was never moved, since moving the real mouse caused it to update the internal QQuickWindowPrivate::lastMousePosition. If the window never got any mouse events, it would therefore fail to generate proper hover events. However, if the window got exposed under a mouse cursor it would generate a hover enter event. We therefore update lastMousePosition when that happens also. Change-Id: I77d9b1bd779a813756c4056b015f2e81664b6d36 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Don't crash when passive grabber deleted before exclusive gr. releasedShawn Rutledge2019-02-262-0/+83
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Blacklist tests in tst_FlickableInteropUlf Hermann2019-02-211-0/+4
| | | | | | | | | touchAndDragHandlerOnFlickable and touchDragFlickableBehindSlider are unstable. Task-number: QTBUG-73983 Change-Id: I220869a0a6e7beb69d7273b0edc66ac067ebcd38 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Make test more robust in case we have interleaved update eventsJan Arve Saether2019-02-131-6/+10
| | | | | | | | | This could for instance happen if the window gets exposed under the cursor, and it sends a mouse move event that might interleave the press and release events, causing the eventCount variable to jump to 3. Change-Id: Icce59b2aa1a937a990baa83f503907633003e2bb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Try to fix flakiness in flickableinterop testUlf Hermann2019-02-071-1/+1
| | | | | | | | The usual problem is that Flickable doesn't instantly jump to the expected position but moves there after a delay. Change-Id: Iafc9dd493b97629377e7f7c60ae7adde13427bae Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix bug where QQMPH kept an exclusive grab when no buttons were pressedJan Arve Sæther2019-02-062-0/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This happened if you moved the mouse while doing a multitouch operation. More specifically this caused the bug: 1. Open qtdeclarative/tests/manual/pointer/map.qml 2. Rotate the map with two fingers (Do not release fingers). 3. Move mouse (no buttons pressed). 4. Release both fingers. 5. Move mouse again (error: the draghandler has a grab and thus the map is dragged even if no buttons are down). This happened because if you moved the mouse while having two fingers down, Windows would generate a *mouse*move* event with Left button or Right button pressed (which wasn't the case on the physical device but it's probably because of a bug in how mouse events are synthesized from touch on Windows). This caused the QQuickMultiPointHandler to do a passive grab. Then, when releasing the fingers it would not send a mouse release event (just plain touch release events), so the QQuickMultiPointHandler would keep the passive grab it had. All subsequent mouse move events would then be dispatched to the QQuickMultiPointHandler where it would assume that the button was pressed until it got a release event (but button was never pressed so that wouldn't happen). Eventually it would perform an exclusive grab, and dragging was initiated. Change-Id: I42b3133c5fde93c7f92f1cb28705156a69f9ad1c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* TapHander: do not "want" an eventPoint that is outside parent boundsShawn Rutledge2019-01-301-3/+7
| | | | | | | | | | | | | | | | | 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>
* PinchHandler: Avoid unwanted translations when axes are disabledShawn Rutledge2019-01-282-1/+89
| | | | | | Fixes: QTBUG-72822 Change-Id: I2773ba14fcb24a47fe2ec04860b4aa305a051453 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add handlers declared as Flickable children to its contentItemShawn Rutledge2019-01-227-0/+570
| | | | | | | | | | | | | | | | | | | | | | | | | | QQuickItemPrivate::data_append() was not invoked when any kind of Pointer Handler was directly declared in a Flickable (or subclass) because QQuickFlickable redefines the default property to be its own flickableData property. So we need to repeat the special handling in QQuickFlickablePrivate::data_append() too. The handler must be added to the private->extra->pointerHandlers vector, so that QQuickItemPrivate::handlePointerEvent() will attempt to deliver events to those handlers. TapHandler seems OK (especially with its default gesturePolicy so that it does not do an exclusive grab). PointHandler seems OK. DragHandler competes with Flickable for the exclusive grab. pressDelay can help; or set acceptedDevices: PointerDevice.Mouse to allow the mouse to drag but not flick, and the touchscreen to flick but not drag. Fixes: QTBUG-71918 Fixes: QTBUG-73035 Change-Id: Icb97ed5230abe0cb6ec0230b5b5759a0528df7e8 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Merge 5.12 into 5.12.1Kari Oikarinen2019-01-082-0/+80
|\ | | | | | | Change-Id: Ic746fbce93430867e2eda4bc7155d34e20a4aa2b
| * TapHandler: ignore scroll events and native gesturesShawn Rutledge2018-12-102-0/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | During a 2-finger press (to emulate right click on a trackpad), the OS may also generate a QWheelEvent with ScrollBegin phase just in case scrolling starts. This must not prematurely deactivate the TapHandler. Also if a gesture or wheel event begins as the very first event after an application starts, ensure that subsequent mouse events are not mis-delivered as wheel or gesture events. Fixes: QTBUG-71955 Change-Id: Ic12e116483ab9ad37c4ac3b1d10ccb62e1349e0a Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | TapHandler: clean up when wantsEventPoint returns falseShawn Rutledge2018-12-132-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already emitted grabCanceled() to inform QML callbacks, but we didn't call reset(). It seems more proper to do everything that would normally be done when grab is canceled. TapHandler should not give up its passive grab yet though, because that prevents delivery to any parent Flickable that might be filtering events. A parent Flickable should be able to start flicking after the drag threshold is exceeded (it happens to be exactly when TapHandler gives up). Fixes: QTBUG-71466 Fixes: QTBUG-71970 Change-Id: Ibba1b0de92cfd88547eeb44edb095d019de76a94 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | PointHandler: distribute simultaneous touch presses properlyShawn Rutledge2018-12-132-0/+165
|/ | | | | | | | | | | | | If multiple touchpoints are pressed simultaneously, each point can be grabbed by one PointHandler instance. Each PointHandler instance cannot grab more than one point, nor grab a point that is already chosen by another PointHandler. This was always the intention, but got broken (perhaps by 3523b676382db4aa39adeb9126d8bb2185e84403), and there was no test coverage of this case until now. Fixes: QTBUG-71431 Change-Id: I6d7614eb4767c677d929291f917cf62d9c03bd93 Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
* Ensure that each Event Handler has an Item parent rather than assertingShawn Rutledge2018-12-072-0/+39
| | | | | | | | | | QQuickItemPrivate::data_append() was already getting called, but the assert (that the parent was already an Item) was failing in case a handler was declared inside a Window or a Dialog. Fixes: QTBUG-71317 Change-Id: Ia497182e3b4a9722eee97a375f9ee5d4151108e6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add dynamically-created Event Handlers to the relevant handlers vectorShawn Rutledge2018-12-073-4/+115
| | | | | | | | | | | | | | | | | If any kind of Pointer Handler is created dynamically in JS by calling Component.createObject(), QObject::setParent() is called rather than passing the parent to the constructor, so QQuickItemPrivate::data_append() did not take care of adding the handler to QQuickItemPrivate's extra->pointerHandlers vector. We need to use the auto-parent mechanism (just as we did with handling dynamic creation of nested Windows in 8cb02e23abbefc9d020707fc1a2d8b6eb4e103b6). Added QQuickItemPrivate::addPointerHandler() to put the prepend() and implied setAcceptedMouseButtons() in one place. Fixes: QTBUG-71427 Change-Id: I3be3dd033c1c89e6e5b5c3463e1a720bbe963281 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Rename QQEventPoint::GrabState to GrabTransitionShawn Rutledge2018-08-312-15/+15
| | | | | | | | | | | | | | | | | | | 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>
* Add a HoverHandler autotestShawn Rutledge2018-08-234-3/+416
| | | | | Change-Id: I223bad4f8117af76ad2a5079ecc0b73c2eba94bc Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Ensure that SinglePointHandler handles touch pointsShawn Rutledge2018-08-221-0/+54
| | | | | | | | | | | A QQuickPointerTouchEvent's button and buttons properties are not currently set (although we had some uncertainty in the past about whether it would be appropriate for a touch press to simulate a left button press). So it seems that f2ba3bd9792500b4d3fcfd23b03098a32641ef4f broke the behavior of PointHandler on touchscreens. Change-Id: I890cc9889e847636c8f385753e47a078ec582195 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* MultiPointHandler: ensure centroid properties are reset after releaseShawn Rutledge2018-08-221-0/+19
| | | | | | | | | | | ...and verify the centroid changes in the DragHandler autotest. It was observable in manual tests that draw velocity vectors that they weren't getting reset to zero after the release, after ca7cdd71ee33f0d77eb6bf1367d2532e26155cb2. Change-Id: I16186d36d51a567b0d653307421147264a5e6326 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QQuickWindow: obey AA_SynthesizeMouseForUnhandledTouchEventsShawn Rutledge2018-08-062-37/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected behavior of QGuiApplicationPrivate::processTouchEvent, but had no effect in Qt Quick. QQuickWindow also accepts the touch event just to make sure that QGuiApplication will not synthesize mouse from touch, because it would be redundant: QQuickWindow does that for itself. Now we make it have an effect in Qt Quick too: skip mouse synthesis if it is set to false. This provides a way to simplify the event delivery. If you set it false, then you cannot manipulate old mouse-only items like MouseArea and Flickable on a touchscreen. (You can of course use event handlers for that.) [ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse event synthesis in QtQuick by calling qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false); This will simplify and speed up event delivery, and it will also prevent any and all interaction with mouse-only items like MouseArea and Flickable on a touchscreen. Task-number: QTBUG-52748 Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* tst_FlickableInterop: use categorized logging rather than qDebugShawn Rutledge2018-08-061-6/+6
| | | | | | | Don't slow down CI for logging unless the test fails. Change-Id: I2d5faedf3fadb30ec5a732445d695bda7e290233 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Add a C++ autotest for PinchHandlerShawn Rutledge2018-08-026-0/+890
| | | | | | | | | | | Adapted from the PinchArea test. cancel() does not work, TDB if we want to support that Done-with: Jan-Arve Sæther <jan-arve.saether@qt.io> Task-number: QTBUG-69134 Change-Id: I63dfba7b327220b9f032f19c588cc19ebdfd95c2 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* tst_MptaInterop::touchesThenPinch: don't forget to flushShawn Rutledge2018-08-021-0/+2
| | | | | | | | The test is actually flaky without that, but it seems to have been missing already. Change-Id: Ic619c66d924c18d3303f1d6bb65d42bc133c56a7 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* MultiPointHandler::wantsPointerEvent: reset if different cand countShawn Rutledge2018-08-021-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Make pinch handler not activate on draggingJan Arve Sæther2018-08-022-4/+11
| | | | | | | | | | | | | | ..when dragging (translation) is disabled In order to do this, we had to integrate QQuickAxis to the PinchHandler which allows enabling/disabling x and y axis individually. This allows us to have one item with PinchHandler with translation disabled (but to only handle rotate and scale) together with a two-finger drag handler. Change-Id: I1581c575ffba2e5d007163bec36e5699bdd86cbc Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* PointHandler: stay active as long as acceptedButtons satisfiedShawn Rutledge2018-07-274-0/+286
| | | | | | | | | Ignore buttons which do not fit the acceptedButtons filter, and do not assume that it's all over when any release happens. Task-number: QTBUG-66360 Change-Id: I871ea7fdd9b76f06fa0d73382617b287c04d35ab Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Call clearGrabbers each time we get a press eventJan Arve Sæther2018-07-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This is important in order for passive grabbers to be in the same order as if the points were pressed at the same time. In our case, the problem occurred when we had a single-point DragHandler together with a two-finger PinchHandler: * One finger was pressed and moved => DragHandler called setPassiveGrab() => point0->passiveGrabbers: [DragHandler] * A second finger was pressed and moved => PinchHandler called setPassiveGrab() for both points => point0->passiveGrabbers: [DragHandler,PinchHandler] => point1->passiveGrabbers: [PinchHandler] So then as one keeps on dragging the *two* fingers, the DragHandler will get the chance to do an exclusive grab first, (since its the first listed passive grabber of point0), and the PinchHandler won't get the opportunity to grab. This is not expected since their declaration order implies that the PinchHandler should get a chance to grab first. Change-Id: I4e82ed186eeb5bf1dae1679d393e5563072175d1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Make DragHandler a MultiPointHandlerShawn Rutledge2018-07-194-95/+105
| | | | | | | | | | That is, minimumPointCount can now be set to a value > 1 to require multiple fingers to do the dragging, or to track the displacement of multiple fingers to adjust some value (such as the tilt of a map). Task-number: QTBUG-68106 Change-Id: Ib35823e36deb81c8b277d3070fcc758c7c019564 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Get rid of Qt.labs.handlers import, merge into QtQuick 2.12Shawn Rutledge2018-07-1714-28/+14
| | | | | | | ... and clean up imports in examples, snippets and tests accordingly. Change-Id: I5bbe63afd2614cdc2c1ec7d179c9acd6bc03b167 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* tst_FlickableInterop: test both usages of DragHandler in a SliderShawn Rutledge2018-07-124-32/+195
| | | | | | | | | | | When there's a DragHandler on one Item and a TapHandler on another, we have more trouble with Flickable stealing the grab. We need a test to ensure that this problem doesn't reappear after fixing. Task-number: QTBUG-64846 Change-Id: Ia3bc3b7c9654f09aa96ad70968d82b566686e030 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Input handler tests: remember positions of stationary pointsShawn Rutledge2018-07-033-23/+26
| | | | | | | | | | | | | | | | | | | We need Handlers to receive accurate positions for stationary touch points: that is, the last-known position from the previous touch event. (And we hope that all actual touch-capable platforms also send proper QPA events with correct positions for stationary points. We assert that it's a bug if they don't.) As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's OK to retain a copy of a QTest::QTouchEventSequence for this purpose, so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not be discarded between events. We have done this in other tests, but not consistently; e.g. 468626e99a90d6ac21cb311cde05c658ccb3b781 fixed the PinchArea test. Change-Id: I4dbe69f8dcc4b1cca30fd7ce91d7d2ecf5ec4bc3 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Add cat. logging in wantsEventPoint; improve FlickableInterop testShawn Rutledge2018-06-292-34/+19
| | | | | | | It was too hard to debug behavior in this test. Change-Id: Iaec9534cca17bdd90b94cfa8fa8b21b7026839ae Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* PinchHandler: rename scale to activeScale; scale means target scaleShawn Rutledge2018-06-271-2/+2
| | | | | | | | | | | | If you want to set target: null and then bind scale to some sort of rendering scale property directly, it's a lot less trouble if the scale property does not keep changing back to 1.0 every time a gesture begins. Added an activeScale property to represent that value, the one that the scale property had before. Task-number: QTBUG-68941 Change-Id: Idcb6735d915a523afe1a948609080af7a83f82ad Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* PointerHandler.grabChanged signal: add stateChange parameterShawn Rutledge2018-06-271-2/+2
| | | | | | | | | 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>
* Make the test pass on my high resolution screenLars Knoll2018-04-251-1/+1
| | | | | Change-Id: I08e952fb8c19c21caf33ffb1cfdc260b533a01d9 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* use nullptr consistently (clang-tidy)Shawn Rutledge2018-02-264-5/+5
| | | | | | | | | | | | | 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>
* Fix draghandler to respect axis constraintsJan Arve Sæther2018-02-211-0/+86
| | | | | | | | | | | | | | | | | | | | | | | ..while its (ancestor) coordinate system has changed during the drag. For example, ensure that a DragHandler-based Slider keeps its knob centered. If the Slider is used on a Flickable which you are flicking with a second finger, then the coordinate system is changing underneath the Slider. The problem was that DragHandler stored the initial drag position of the target when the target item was pressed, and used that throughout the whole drag operation. Unfortunately if the target item was inside a Flickable that got flicked during a drag operation, that initial position was not updated (and thus, incorrect). Instead of storing the initial target position in scene coordinates, we now store the position that got pressed in local target coordinates, and ensure that in any further updates the touchpoint have the same local position (by moving the target). Task-number: QTBUG-64852 Change-Id: I25012d34d88f45c7eb9c711db0037d530cf10854 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Merge remote-tracking branch 'origin/5.10.1' into 5.11Qt Forward Merge Bot2018-02-151-0/+14
|\ | | | | | | Change-Id: I64bf7d183bbd8af7282270097809d14a54ba0188
| * Make sure passive grabbers are cleared on releaseJan Arve Saether2018-02-021-0/+14
| | | | | | | | | | | | | | | | | | This got regressed by change e6d4df156e9aec62054740dc99ab8ba2855eaafc. Before that change, we always cleared both the exclusive and passive grabbers. Task-number: QTBUG-66152 Change-Id: I93d2568bd2a23ddd55a5294d544f978a50a5543e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/5.10' into 5.11Liang Qi2018-02-125-9/+212
|\| | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/imports/shapes/qquickshape.cpp src/imports/shapes/qquickshape_p_p.h src/qml/compiler/qqmlpropertycachecreator_p.h src/qml/jsruntime/qv4value_p.h src/quick/items/qquickloader_p.h tests/auto/qml/qqmlecmascript/tst_qqmlecmascript.cpp tools/qmlprofiler/qmlprofilerapplication.cpp Change-Id: Iafc66ae84bf78630ed72a986acb678e9d19e3a69
| * Change default TapHandler.gesturePolicy to DragThresholdShawn Rutledge2018-01-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This is based on the idea that TapHandler may be more often used to modify existing behavior rather than building Button controls from scratch. DragThreshold is reasonable newbie-friendly default behavior for both use cases. The drag-off-drag-back-release-and-click behavior is more advanced, and the designers of the best-behaving Button controls can be expected to discover the need to change gesturePolicy to get it. Change-Id: If220acf080e04f664d020d5e832f8d16a16b857a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
| * Do not stop delivering to handlers if all points are acceptedJan Arve Saether2018-01-314-9/+211
| | | | | | | | | | | | | | | | | | | | | | Some Pointer Handlers can perform the desired interaction using only passive grabs. When such a handler is used to modify behavior of another event-handling Item or Handler which needs to take the exclusive grab, this allows them to cooperate: both can see the updates, and neither prevents delivery of events to both. Change-Id: I312cc301c52fcdf805245bbe0ac60fd28f92c01f Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Stabilize the flickableinterop autotestLars Knoll2018-02-081-2/+2
|/ | | | | | | | | | Make sure the Rectangles we're sending the touch events to are visible on screen, otherwise I get consistent failures in this test on Linux. Change-Id: Icc2ba7ba73c434dd2ef725adbaa57ab6d413f354 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-30 20:38:25 +0000