aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/qquickflickable/tst_qquickflickable.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Flickable: prevent fixup() from being called while draggingOliver Eftevaag2022-12-191-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A previous patch 5647527a8cde84b51fff66fc482f02435770b3dd causes a regression. The purpose of the patch, that caused this regression, was to update the pressPos variables, in cases where the contentItem's geometry was modified externally, while a user were dragging the contentItem around. The mistake that was made, was how width and height changes were handled. We had previously added logic in setContentWidth() and setContentHeight() that would call fixup() (with immediate fixupMode) to ensure that the contentItem would immediately be repositioned inside the flickable's viewport, if the contentItem was being dragged. It turns out that setContentWidth() and setContentHeight() are being called from QQuickItemViewPrivate::updateViewport(), which happens quite often, while dragging. This would make fixup() and dragging constantly interfere with each other, since they'd not always agree on a specific position for the contentItem. This patch reverts the changes made to setContentWidth() and setContentHeight(), since it turns out that those changes weren't necessary after all. QQuickFlickablePrivate::itemGeometryChanged() only calls viewportMoved() on x and y changes anyways. Done-with: Jan Arve Sæther <jan-arve.saether@qt.io> Done-with: Santhosh Kumar Selvaraj <santhosh.kumar.selvaraj@qt.io> Fixes: QTBUG-109140 Change-Id: I0bddf8685d3afc1ae04b2c092212d3c1bd742c3b Reviewed-by: Paul Wicking <paul.wicking@qt.io> (cherry picked from commit b307bf3c4f63c6e04874a972c747f18e18ddc199) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Flickable: let changing contentItem pos also affect the drag starting posOliver Eftevaag2022-09-021-1/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When calling the setContentX(qreal) and setContentY(qreal) functions, the flickable would not update the drag starting position if they were called in the middle of a dragging operation. This patch makes those function update the drag starting position, so that the drag will take into account the external changes to the contentItem position, and not make any massive leaps on the next call to drag() after changing the contentItem position directly. Note that vData.pressPos and hData.pressPos are set to the x and y position of the contentItem at the beginning of a drag operation. They are unrelated to the mouse position. The bug QTBUG-104966 will be fixed from this, since QQuickItemView::setModel() calls QQuickListViewPrivate::setPosition() which calls QQuickFlickable::setContentX/Y(). The QQuickFlickable::setContentX/Y functions are public (part of the public API). They will update the timeline value for the x and y axis, which will as a result also call setViewportX/Y, which calls setX/Y for the contentItem itself. Done-with: Jan Arve Sæther <jan-arve.saether@qt.io> Fixes: QTBUG-104966 Change-Id: Id5165e1ff37a07b94be8c1cc152e86dfcc13d1c6 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> (cherry picked from commit 5647527a8cde84b51fff66fc482f02435770b3dd)
* Flickable: Fix edge hitting detection when the extent is fractionalOliver Eftevaag2022-06-271-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the extent is fractional, the updateBeginningEnd() function would not be able to detect if the contentItem is hitting an edge or not. This is because the target move position for when a flick is initiated, is at some point rounded (in QQuickFlickablePrivate::fixup()), while the extent is not. This patch will ceil the minExtent/topMargin, before checking whether the contentItem y position is hitting it or not. This value is normally negative, and the ceil will thus be closer to 0. This will mean that if the target move position is rounded to be closer to 0, it will now count that as hitting the edge, even in cases when the topMargin is a few subpixels further away (which is not visually noticeable). The same logic is applied to the maxExtent/bottomMargin, and for the x axis. Furthermore, this patch also improves the scrolling logic in wheelEvent, ensuring that flickingStarted() and movingStarted() are not called unless 1) the contentItem is currently standing still, and 2) the scrolling isn't directed towards the edge while the contentItem is near it (no movement should occur in this case). Here is a more holistic expanation for what was happening in the reported bug: Scrolling a flickable will cause an "artificial" flick, unless the user has scrolled the maximum distance in a particular direction. When flicking, a timeline is started with a goal for what the contentItem's position should end up being when the timeline completes. As the timeline advances, it will callback the fixup function, which will round the target x and y move position for the contentItem. Which is used to check whether the contentItem is hitting an edge or not. A fuzzy compare is being done here, but since the extent isn't being rounded, it will fail when the extent is fractional. When you scroll with the wheel, QQuickFlickable::wheelEvent will typically be called a couple of times, and we don't want to call flickingStarted() or movementStarted() when the Flickable has already scrolled to its limit in a particular direction (an edge). While calling flickY() is undesired in this situation, the larger problem is movementStarted(). This function will set the the moving flag in vData to true. The moving flag in the hData and vData is used in a lot of different places, to figure out what to do in special situations (like resizing the window). But the moving flag is only set to false upon a call to timelineCompleted() (which unsurprisingly is called when the timeline is completed). What was happening in the reported bug, is the following: 1. wheelEvent() is called, and starts flicking the listview towards the edge. 2. The destination for the flick is rounded, to have a lower absolute value than the extent. 3. Any subsequent calls to wheelEvent() will also call flickY() and movementStarted(), setting the moving flag to true, even though no movement is occurring (since the contentItem has already reached it's maximum or minimum value). 4. Since flickY() isn't really doing much when it's called (since the source value == destination value), it will cause the timeline to complete instantly, inside the flickY() call. This would lead to the moving flag being set to true in the movementStarted() function, that is called right after flickY() in wheelEvent(). The moving flag would remain true forever, since timelineCompleted() must be called for it to become false again, but that function was called before movingStarted(). The user would need to flick in a different direction for it to go back to false again. 5. Since the vData.moving flag is set to true, fixupY() will not get called from QQuickFlickable::geometryChange() (when resizing the window). Normally, when resizing the window, the adjustContentPos() will get called, which will provide the timeline with the correct new contentItem position, and use the Immediate fixupMode, that will cause the timeline to complete immediately. If the vData.moving flag is true, all of these fixup steps will be skipped during geometryChange(), which was the case in the reported bug. In the above description, I've mostly been talking about the behavior that happens when scrolling in the vertical direction, but I see no reason why this couldn't theoretically happen in the horizontal direction as well. Therefore, I am applying the same fix for scrolling horizontally. Fixes: QTBUG-101268 Fixes: QTBUG-101266 Change-Id: I0e56290541a9f28a5489d92251f059e7448184f0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit 833f83f270e844265905e4657ef74319b7b8b68f) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Handle unprocessed pressed case in FlickableAntti Määttä2022-06-221-0/+22
| | | | | | | | | | | | | | | | Handle case where Flickable filters a pressed event before the receiver has decided whether it wants to keep the grab. That causes the Flickable to not process the press event, but still processes all the later events. This happens when the receiver is MouseArea so add special case for it in Flickable, where we start the drag if all conditions are met. Fixes: QTBUG-38765 Fixes: QTBUG-74842 Change-Id: I2e02042cb496e9eb3b7b5da824e56f76ee76ccbb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit d7b5a485583004ad6a1374a50b7c3f6cab00aca3) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* tst_qquickflickable: fix UB (more % in format string than arguments)Marc Mutz2022-05-261-1/+1
| | | | | | | | | | | Provide the third argument. Amends 8068bde891eefe99a43deb83e58166b476f65225. Change-Id: I7f4b0043a64aae5e998309b9ea2332b6e86e2d74 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit 83f18c3191fd27ea66e0d4e9ade50e94ae8da091) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* QQuickFlickable: fix flicking when item is rotatedShawn Rutledge2022-05-121-0/+53
| | | | | | | | | | | | | | | | | | | | | | QEventPoint::velocity() is in screen coordinates, as documented; it needs to be transformed to local coordinates in case the Flickable is rotated and/or scaled. windowToItemTransform() gives us a composite transform matrix; we remove the translation components to get only the rotation and scaling. Also fix the press position calculation in handleReleaseEvent(). With the manual test one can pinch to scale and rotate a Flickable, then verify that with a single finger, the Flickable gets scrolled by an appropriate distance in spite of that. Done-with: Ivan Solovev Fixes: QTBUG-99639 Change-Id: I60af1dd932835d358baa1422523cc24b2ab046a0 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io> (cherry picked from commit 8068bde891eefe99a43deb83e58166b476f65225) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Respect the pixelAligned property when updating the visible areaLars Knoll2022-05-111-9/+35
| | | | | | | | | | | | | | | Ensure the QQuickFlickableVisibleArea correctly calculates the visible area when the pixelAligned property is set. Add test data for it to the overshoot() test case. The test would sometimes fail locally and not flick far enough. Stabilize it by using a larger flick velocity. Fixes: QTBUG-77055 Change-Id: Ied424c6e59d2dc4737ea3f88854daa7939930a97 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit d597172fcd11ed3d3a73d2648415bd01ff7487c1) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* QQuickFlickable: use custom content item that takes extents into accountRichard Moe Gustavsen2022-03-221-0/+58
| | | | | | | | | | | | | | | | | | | The flickable area inside the viewport can be bigger than the bounds of the content item itself, if the flickable is using non-zero extents (as returned by e.g minXExtent()). Since the default implementation in QQuickItem::contains() only checks if the point is inside the bounds of the item, we need to override it to check the extents as well. This patch will implement a new QQuickItem that overrides contains(). It will simply check if the point is inside the bounds of the flickable rather than the content item itself. Fixes: QTBUG-101386 Change-Id: Ifb27e899e40fde80a75e8bbbf88dd858053898af Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit 768716c3f4aa4d6be953092ee737f93477164479) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Flickable: don't react to any mouse button other than the leftShawn Rutledge2021-09-281-0/+50
| | | | | | | | | | In case of mouse "chording", ignore all other buttons. Pick-to: 6.2 6.1 5.15 Fixes: QTBUG-96909 Change-Id: Ib091b271390c5b4e3aafbbe24d2dc7b6f08db175 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Consolidate test helpers into private librariesMitch Curtis2021-09-131-54/+55
| | | | | | | | | | | | | | | | | | | | Previously each test would include and build sources from the shared folder. Now we make those sources a library, build it once, then have each test link to it instead. We also take the opportunity to move some helpers that qtquickcontrols2 had added into the quicktestutils library where it makes sense, and for the helpers that don't make sense to be there, move them into quickcontrolstestutils. We add the libraries to src/ so that they are internal modules built as part of Qt, rather than tests. That way we can use them in a standalone test outside of qtdeclarative. Task-number: QTBUG-95621 Pick-to: 6.2 Change-Id: I0a2ab3976fdbff2e4414df7bdc0808f16453b80a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix Flickable wheel velocity calculationShawn Rutledge2021-07-091-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Angular velocity is defined as angle rotated divided by time elapsed. But the historical problem with Flickable is that the calculation ignored time, as if there was a maximum frequency of events and we only needed to know the rotation angle per fixed unit of time. With "clicky" mouse wheels perhaps it was a reasonable approximation. With touchpads that provide pixel deltas, we've been doing the velocity calculation the right way since a6ed830f4779e218b8e8f8d82dc4aa9b4b4528a1 Now we divide by dt also in the wheel rotation case. That gives instantaneous velocity. Next question: how to do smoothing? AxisData::velocityBuffer is basically a Kalman filter, but until now it was used only when dragging ends and we animate the deceleration from the velocity at that time. It seems to work well for smoothing the velocity that comes from wheel events, too. So now we use that instead of smoothVelocity, and it stays in control better. Next question: when a series of wheel events occurs, we have valid dt for the dy / dt velocity calculation (or dx / dt horizontally), but what about the initial flick? What if first thing the user does is rotate a physical mouse wheel by one "click", how far should Flickable move before it comes to rest? QStyleHints::wheelScrollLines() tells us how far to move for one wheel event... in "lines", whatever that is. Flickable doesn't know about its contents. But it "feels" reasonable if we define a "line" as 24 pixels. At least the setting will do something now: applications can adjust it, and some system control panels can adjust it. A subclass of QQuickFlickable (such as TableView) could even change QQFlickablePrivate::initialWheelFlickDistance to be the actual number of pixels per "line", to scroll exactly by rows. (But when the events occur faster, it moves further and faster, like it always did.) OK so we know how far we want to move when the Flickable is at rest and receives a QWheelEvent with angleDelta of 120. I.e. when isMoving() is false. So I tried an experiment: set dt to 0.25. How far did it move? 77 pixels. Why? We're making it move via QQuickFlickablePrivate::flick() which does some math and drives the timeline. The key formula is qreal dist = v2 / (accel * 2.0) which agrees with the testing: if the wheel turns by 120 units, (120 / 0.25)^2 / (1500 * 2) =~ 77 So it's possible to do the algebra to reverse-engineer what dt should be so that we will move the right distance with a single wheel event, despite the complexity of the animation itself. That's what is now done. When the user rotates the wheel very slowly, it moves by discrete amounts but with smooth animation. A little faster, and it speeds up, somewhat like it did before, but with more control. If it has sped up to a high speed and then the user rotates the wheel backwards, it reverses instantly: we clear the Kalman filter and insert instantaneous velocity (so it will go from there at the next event). On a touchpad, it also feels quite in-control because the velocity is calculated properly as distance-delta / time-delta. Smoothing it out doesn't hurt, and animating after release doesn't hurt. It longer goes "zing" out of control when the wheel events come in too frequently from a touchpad or a free-spinning wheel. None of this affects trackpads on macOS, because then the wheel events have phases and pixel deltas, and we don't use this animation. We still should try to get that working on as many OSes as possible, eventually. Clarify the meaning of the flickDeceleration property. [ChangeLog][QtQuick][Flickable] Flickable no longer tries to detect whether you're using a "clicky" wheel or a touchpad, but rather does the velocity calculation more correctly with elapsed time (dθ / dt). A single rotation of a "clicky" wheel also moves a fixed distance, which is now adjustable via QStyleHints::wheelScrollLines(). Animation is restored, but should now stay in control on touchpads; and it will once again transition the "moving" properties correctly when scrolling ends. Fixes: QTBUG-56075 Pick-to: 6.2 Change-Id: I5166ca31c86335641cf407a922a3a970fced653d Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Make tst_qquickflickable check scaling of drag thresholdShawn Rutledge2021-05-061-3/+12
| | | | | | | | | | | | | | | | | We continue to enforce the drag threshold in local (transformed) coordinates: if Flickable should wait until the user drags 12 pixels, but it's scaled to half-size, it will start dragging after only 6 pixels of movement, for example. But if it's also rotated, then the required distance becomes a projection of the actual drag vector onto the vector along which the Flickable should move past the (scaled) drag threshold. I.e. if we rotate the Flickable's parent by 45°, the required distance should be 12 / 2 * √2 ≈ 8.5; 9 pixels will exceed the threshold, then. tst_qquickflickable::clickAndDragWhenTransformed is modified to prove it (at least when a 2D scale is applied). The test should be OK on hidpi because qApp->styleHints()->startDragDistance() is already adjusted. Change-Id: I035a462c75e7c5aba876a67c1b996bccab2c5364 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Use logical OR to test boolsVolker Hilsheimer2021-03-181-1/+1
| | | | | | Pick-to: 6.1 Change-Id: I021c3354932584cb976d3529ff47f7a826731336 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Flickable: ignore trackpad events with px deltas in disallowed directionShawn Rutledge2021-01-151-0/+61
| | | | | | | | | | | | | | | | If Flickable.flickDirection == HorizontalFlick, then if the accumulated QWheelEvent::pixelDelta()'s abs(dx) > 2 * abs(dy), clearly the user is trying to scroll horizontally; otherwise, don't accept the event. That way the event is allowed to propagate to a parent Flickable that does allow flicking vertically. Likewise if the nesting is the other way around, only allow the inner vertical Flickable to accept if the flicking is actually vertical. Fixes: QTBUG-57245 Fixes: QTBUG-80236 Pick-to: 6.0 Change-Id: Ieb0bf9310a67210ce7e9fe7a80c88baef2cc7ede Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix tests that used out-of-context mouse grabsShawn Rutledge2020-11-171-4/+4
| | | | | | | | | | QQuickItem::grabMouse() is deprecated, and cannot be used at all when there is no current event being delivered. But we can still use QPointingDevicePrivate::setExclusiveGrabber(). Task-number: QTBUG-86729 Change-Id: I215de471e6dc44551720bc4c766b22cdfee94423 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add tst_qquickflickable::parallelTouchShawn Rutledge2020-11-171-0/+43
| | | | | | | | | | | Prove that we can drag multiple Flickables with multiple touchpoints now. [ChangeLog][QtQuick][Flickable] Flickable now handles touch events directly: you can now drag multiple Flickables with multiple touchpoints. Fixes: QTBUG-30840 Change-Id: I0a3e58595a67f5afb4b93ad64d5280cb3fc52f7a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Don't synthesize mouse from touch for items that accept touchShawn Rutledge2020-11-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Followup to 1457df74f4c1d770e1e820de8cd082be1bd2489e : if an item that has acceptTouchEvents() == true merely fails to accept one touch event, that does not mean a mouse event should be sent. Finish changing the default to false: handling touch events is opt-in, just like handling mouse events; most items don't. And if you opt in, then you MUST handle touch events, because you will NOT receive mouse events as a fall-back. Now that Flickable handles touch, filtering multi-touch events becomes relevant. There was a failure in tst_touchmouse::mouseOnFlickableOnPinch when Flickable grabs a stationary touchpoint at the same time as another touchpoint is pressed, preventing a child PinchArea from reacting. So there's a new rule: just as we start over with event delivery when a new point is pressed, QQuickFlickable::filterPointerEvent() should also not immediately grab when any point is newly pressed; it can afford to wait, because it's filtering, so it will be able to see if one point is dragged past the drag threshold later on. When a parent (such as Flickable) contains only mouse-handling items (such as MouseArea), the parent should filter the touch event if it is able (if acceptTouchEvents() returns true). Flickable is now able to. Filtering parents that are not able to filter touch events can still filter a synth-mouse event as before. But filtering both must be avoided: then we would have the problem that Flickable filters a touch move, sees that it's being dragged past the drag threshold, and sets d->stealMouse to true to indicate that it wants to steal the _next_ event; then it filters a synth-mouse move, and that's perceived as being the next event even though it's just a different view of the same event, so it steals it. In tst_qquickflickable::nestedMouseAreaUsingTouch we rely on the delay caused by waiting for the next event: the MouseArea is trying to drag an item and the Flickable wants to flick; both of them decide on the same event that the drag threshold is exceeded. But MouseArea calls setKeepMouseGrab() immediately, whereas Flickable doesn't try to steal the grab until the next event, and then it sees the keepMouseGrab flag has been set, so it doesn't do it. If Flickable could filter the same event twice (once as touch, once as synth-mouse), this logic doesn't work, so it's effectively "more grabby" than intended. So it works better to have it filter only the actual touch event, not the synth-mouse that comes after. When the child has pointer handlers, we need to visit them, and therefore we should let Flickable filter a touch event on the way. tst_FlickableInterop::touchDragFlickableBehindButton() depends on this. [ChangeLog][QtQuick][QQuickWindow] In Qt 6, a QQuickItem subclass must explicitly call setAcceptTouchEvents(true) to receive QTouchEvents, and then it must handle them: we no longer fall back to sending a QMouseEvent if the touch event is not accepted. If it has additionally called setFiltersChildMouseEvents(true), then it will filter touch events, not any synthetic mouse events that may be needed for some children. Task-number: QTBUG-87018 Fixes: QTBUG-88169 Change-Id: I8784fe097198c99c754c4ebe205bef8fe490f6f4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix compile warnings from testsVolker Hilsheimer2020-10-221-1/+1
| | | | | | | | | | | Use streaming operators for debug/warnings to avoid qsizehint/int conflicts. Don't ignore return values from [[no_discard]] functions. Don't copy elements from containers that return references. Remove unused variables. Change-Id: I7a0bef94a5e828bd8facee0c625ec48c3d1f1bdb Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Speed up tst_qquickflickableShawn Rutledge2020-10-141-3/+0
| | | | | | | Speed up animations that the test spends too much time waiting to complete. Change-Id: I7941660f3c3a89798c5cdd0eee8018a44fb89a0d Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Handle ungrab and grab-cancel consistently; inform handlersShawn Rutledge2020-09-261-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Call onGrabChanged on Pointer Handlers during grab transitions: this was missing in a97759a336c597327cb82eebc9f45c793aec32c9. Flickable needs to receive an ungrab by child-event-filtering, in order to set its pressed state back to false (as in the cancelOnHide autotest). This is best done as a result of the QPointingDevice::grabChanged signal, while trying to send the ungrab to the item that was the grabber, rather than as a special case. Thus, QQuickWindowPrivate::onGrabChanged (the handler for the QPointingDevice::grabChanged signal) is now the only place from which we call QQuickItem::mouseUngrabEvent() and touchUngrabEvent(). But the result is that they are called in more cases than before, so some tests need adjustment. touchUngrabEvent() is not sent unless the event is available and we can verify that all points have been released. This is important for MultiPointTouchArea: it will react by ending interaction with all points at once. Another thing that's important to MPTA and multi-touch handlers is that QQuickWindowPrivate::deliverPointerEvent() must not clear grabbers of points that are not yet released, in the case that only some points are. QQuickWindowPrivate::removeGrabber() now calls QPointingDevicePrivate::removeGrabber() with its optional cancel argument, so that it will emit either a cancel or an ungrab transition. That's only relevant for Pointer Handlers, whereas QQuickItem mouseUngrabEvent and touchUngrabEvent don't make a distinction. Task-number: QTBUG-86729 Change-Id: Idf03aef2e2182398e0fc4a606c0ddbb2aaed5681 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Remove QQuickPointerEvent etc.; deliver QPointerEvents directlyShawn Rutledge2020-09-181-6/+5
| | | | | | | | | | | | | | | | | | | | | | | QEventPoint does not have an accessor to get the QPointerEvent that it came from, because that's inconsistent with the idea that QPointerEvent instances are temporary, stack-allocated and movable (the pointer would often be wrong or null, therefore could not be relied upon). So most functions that worked directly with QQuickEventPoint before (which fortunately are still private API) now need to receive the QPointerEvent too, which we choose to pass by pointer. QEventPoint is always passed by reference (const where possible) to be consistent with functions in QPointerEvent that take QEventPoint by reference. QEventPoint::velocity() should be always in scene coordinates now, which saves us the trouble of transforming it to each item's coordinate system during delivery, but means that it will need to be done in handlers or applications sometimes. If we were going to transform it, it would be important to also store the sceneVelocity separately in QEventPoint so that the transformation could be done repeatedly for different items. Task-number: QTBUG-72173 Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Replace QTouchEvent::TouchPoint with QEventPointShawn Rutledge2020-07-151-6/+6
| | | | | | | | | | | | It's a cosmetic change at this time, because we have declared using TouchPoint = QEventPoint; Also replace Qt::TouchPointState enum with QEventPoint::State. Task-number: QTBUG-72173 Change-Id: Ife017aa98801c28abc6cccd106f47a95421549de Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Use QList instead of QVectorJarek Kobus2020-06-251-1/+1
| | | | | | Task-number: QTBUG-84469 Change-Id: I4c3353c00a566023503fbc178ba8454391dc334c Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Remove QQuickPointerDevice in favor of QPointingDeviceShawn Rutledge2020-06-231-2/+1
| | | | | | | | | | | | | | ...and generally deal with changes immediately required after adding QInputDevice and QPointingDevice. Also fixed a few usages of deprecated accessors that weren't taken care of in 212c2bffbb041aee0e3c9a7f0551ef151ed2d3ad. Task-number: QTBUG-46412 Task-number: QTBUG-69433 Task-number: QTBUG-72167 Change-Id: I93a2643162878afa216556f10808fd92e0b20071 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Replace calls to deprecated QEvent accessor functionsShawn Rutledge2020-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | Several event accessors were deprecated in qtbase/24e52c10deedbaef833c0e2c3ee7bee03eacc4f5. Replacements were generated by clazy using the new qevent-accessors check: $ export CLAZY_CHECKS=qevent-accessors $ export CLAZY_EXPORT_FIXES=1 $ ../qt6/configure -platform linux-clang -developer-build -debug -no-optimize-debug -opensource -confirm-license -no-pch QMAKE_CXX=clazy $ make $ cd ../../qt6/qtdeclarative $ find . -name "*.clazy.yaml" $ clang-apply-replacements . Task-number: QTBUG-20885 Task-number: QTBUG-84775 Change-Id: I1be5819506fd5039e86b4494223acbe193e6b0c9 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-02-061-0/+11
|\ | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/qml/types/qqmlbind.cpp src/quick/items/qquicklistview.cpp tests/auto/qml/qqmllanguage/tst_qqmllanguage.cpp Change-Id: Id6805c13256ad13d5651011e5dd09bba0ec02987
| * QQuickFlickable: fix division by zeroMitch Curtis2020-01-291-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The issue could be seen when enabling exceptions and running the following QML code: Flickable { id: flickable anchors.fill: parent contentWidth: 1000 contentHeight: 1000 Text { text: flickable.visibleArea.xPosition } } Change-Id: I615f9f9dc84903fb3a902f416a55e3ce3fece64c Fixes: QTBUG-81098 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* | tst_qquickflickable: avoid setContextPropertyFabian Kosmale2019-10-071-4/+3
|/ | | | | Change-Id: Iaf123e647143275cfc9efcd39a1cd5944d599972 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Remove usages of deprecated APIs of QWheelEventSona Kurazyan2019-08-231-5/+10
| | | | | | Task-number: QTBUG-76491 Change-Id: I69b0c4ec7c03f9421b18828516e064eff2b45518 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Always waitForWindow after centerOnScreen()Dimitrios Apostolou2019-07-221-0/+3
| | | | | | | | | | | | | | | Because centerOnScreen asks the window manager to move the window, but does not wait for it. This is applied in the same spirit as this change in qtquickcontrols2: https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/268200 These tests appear slightly flaky on the Grafana dashboard, this commit might help. Change-Id: I30d3f4717aca435c94fb1a447c4b5c51021da3be Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Stabilize nestedSliderUsingTouch:keepNeither test on UbuntuShawn Rutledge2018-09-131-4/+4
| | | | | | | | | | | | | | | | For whatever reason, it seems we have to be less strict about the exact number of touchpoint movements that the TouchDragArea will see while being dragged 8 times. Counting those is really far from the main point of this test anyway. Also removed blacklisting of macOS 10.10 tests since we don't even support 10.11 anymore. Task-number: QTBUG-36804 Task-number: QTBUG-59840 Fixes: QTBUG-68867 Change-Id: I8f856c5b29de08f55dcd0273cd99dcda77cdf2c3 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Increase fine-grained signals for some properties in FlickableAleix Pol2018-07-311-0/+9
| | | | | | | | | | | | Flickable.at[X/Y][Beginning/End] were being always notified of changes at bulk. This is can be harmful in performance of QML applications that will trigger change requests on the program whenever a property is modified. This introduces separate signals so it's not a problem anymore. Change-Id: I729852df665ec34f532812dd0a45507d053d624c Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* Add Flickable.synchronousDrag propertyShawn Rutledge2018-07-121-0/+66
| | | | | | | | | | | | | | | When it is set true, Flickable begins dragging by making the content jump to the position where it would have been if there was no drag threshold: that is, the content moves exactly in sync with the mouse cursor or finger (as long as it's not hitting the bounds). [ChangeLog][QtQuick][Flickable] Added a synchronousDrag property that makes the content jump to the position it would have had if there was no drag threshold, as soon as dragging begins. Task-number: QTBUG-62902 Change-Id: I5f3b530956363172167896b0f19aec4a41bf82b3 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* use nullptr consistently (clang-tidy)Shawn Rutledge2018-02-261-80/+80
| | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'origin/5.9' into 5.11Liang Qi2018-02-181-1/+1
|\ | | | | | | | | | | | | | | Conflicts: .qmake.conf tests/auto/qml/qqmlcontext/tst_qqmlcontext.cpp Change-Id: I7feb9772fc35066f56b7c073482b53ca8c86c70b
| * tst_qquickflickable: fix compiler warningMitch Curtis2018-02-081-1/+1
| | | | | | | | | | | | | | | | | | tst_qquickflickable.cpp:822:47: warning: ignoring return value of ‘bool QTest::qWaitForWindowActive(QWindow*, int)’, declared with attribute warn_unused_result [-Wunused-result] Change-Id: I39be58a1032e36f650ce2e008026faaf368cca3f Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | test: tst_qquickflickable::flickOnRelease() got fixedLiang Qi2018-01-091-6/+0
| | | | | | | | | | | | | | | | Task-number: QTBUG-26094 Task-number: QTBUG-65343 Change-Id: Iee5347227cc943ae6d5d9ba480c0fb8024d258aa Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/5.10' into devLiang Qi2017-12-201-0/+8
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: tests/auto/quick/pointerhandlers/flickableinterop/data/FlashAnimation.qml tests/auto/quick/pointerhandlers/flickableinterop/data/Slider.qml tests/auto/quick/pointerhandlers/flickableinterop/data/TapHandlerButton.qml tests/auto/quick/pointerhandlers/flickableinterop/data/flickableWithHandlers.qml tests/auto/quick/pointerhandlers/multipointtoucharea_interop/data/pinchDragMPTA.qml tests/auto/quick/pointerhandlers/qquickdraghandler/data/DragAnywhereSlider.qml tests/auto/quick/pointerhandlers/qquickdraghandler/data/FlashAnimation.qml tests/auto/quick/pointerhandlers/qquickdraghandler/data/Slider.qml tests/auto/quick/pointerhandlers/qquickdraghandler/data/draggables.qml tests/auto/quick/pointerhandlers/qquickdraghandler/data/multipleSliders.qml tests/auto/quick/pointerhandlers/qquicktaphandler/data/Button.qml tests/auto/quick/pointerhandlers/qquicktaphandler/data/FlashAnimation.qml tests/auto/quick/pointerhandlers/qquicktaphandler/data/buttons.qml tests/manual/pointer/content/FakeFlickable.qml tests/manual/pointer/content/FlashAnimation.qml tests/manual/pointer/content/MomentumAnimation.qml tests/manual/pointer/content/MouseAreaButton.qml tests/manual/pointer/content/MouseAreaSlider.qml tests/manual/pointer/content/MptaButton.qml tests/manual/pointer/content/MultiButton.qml tests/manual/pointer/content/ScrollBar.qml tests/manual/pointer/content/Slider.qml tests/manual/pointer/content/TapHandlerButton.qml tests/manual/pointer/fakeFlickable.qml tests/manual/pointer/flickableWithHandlers.qml tests/manual/pointer/flingAnimation.qml tests/manual/pointer/joystick.qml tests/manual/pointer/main.cpp tests/manual/pointer/main.qml tests/manual/pointer/map.qml tests/manual/pointer/map2.qml tests/manual/pointer/mixer.qml tests/manual/pointer/multibuttons.qml tests/manual/pointer/photosurface.qml tests/manual/pointer/pinchDragFlingMPTA.qml tests/manual/pointer/pinchHandler.qml tests/manual/pointer/singlePointHandlerProperties.qml tests/manual/pointer/tapHandler.qml tests/manual/pointer/tapWithModifiers.qml tests/manual/shapestest/main.cpp Change-Id: I4f233a521305fab1ebfecbac801da192434ed524
| * | Merge remote-tracking branch 'origin/5.9' into 5.10v5.10.0-beta4Liang Qi2017-11-061-0/+8
| |\| | | | | | | | | | Change-Id: I8ede7e36592cd21f3e4a0a9b30dbe26bb40fe69b
| | * QQuickFlickable: Use QQuickItem::setSize() in resizeContent()Alexandr Akulich2017-11-031-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Sequential call of setWidth() and setHeight() results in outdated height on widthChanged() signal. Use setSize() to set width and height at once. Change-Id: I013f5e1fcfc65a8606f9596ddc196b633873dc98 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | | test: skip tst_qquickflickable::flickOnRelease()Liang Qi2017-12-191-1/+2
|/ / | | | | | | | | | | | | | | It will be fixed when new qt5 dev integrated. Task-number: QTBUG-65343 Change-Id: Ic048d7a1480b023dc86d51d1d4de517a63dbedda Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Default QQuickItem::acceptTouchEvents to true until Qt 6Shawn Rutledge2017-05-101-0/+4
| | | | | | | | | | | | | | | | This is a partial revert of 1457df74f4c1d770e1e820de8cd082be1bd2489e to avoid making a mandatory API change so soon. Change-Id: I05040579fa36d3dc5ef7616861f6d17adf500d2c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Add QQuickItem acceptTouchEvents/setAcceptTouchEvents; require for touchShawn Rutledge2017-04-141-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It has been suboptimal to speculatively deliver touch events to Items which are not interested; even worse is when we must deliver to a parent item which is filtering events, when the child Item will not accept the touch event anyway. So now it is required that any QQuickItem subclass which wishes to accept touch events must call setAcceptTouchEvents(true) (typically in its constructor). If it does not do this, it will not get any touch events (and this saves us the trouble of looking for parents which filter touch events, too). It is consistent with needing to call setAcceptHoverEvents() to get hover events, and setAcceptedMouseButtons() to get mouse events. [ChangeLog][QtQuick][QQuickItem] When subclassing QQuickItem, it is now required to call setAcceptTouchEvents(true) if you need the item to receive touch events. Change-Id: Idc76c04f4e7f1d4a613087e756e96dac368f4f23 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Allow custom bounds behaviors for FlickableJ-P Nurmi2017-04-101-49/+94
|/ | | | | | | | | | | [ChangeLog][QtQuick][Flickable] Added a boundsMovement property that allows disabling the default bounce effect and implementing custom edge effects. Task-number: QTBUG-38515 Change-Id: Id00d30a863e264cdbac00fbad8189406f29484c4 Reviewed-by: Robin Burchell <robin.burchell@crimson.no> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* tst_qquickflickable: remove bogus ItemAcceptsDrops flagShawn Rutledge2017-04-051-3/+1
| | | | | | | | TouchDragArea (only for the nestedSliderUsingTouch test so far) doesn't need this flag. It was a copy-and-paste mistake. Change-Id: I4aba79f940e89c9b5f91f2a347c1b7f458284e24 Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* Adapt tst_qquickflickable::nestedSliderUsingTouch for slow CIShawn Rutledge2017-04-041-4/+4
| | | | | | | | | QQuickTouchUtils::flush() doesn't actually cause all events to be fully delivered. Task-number: QTBUG-59840 Change-Id: Id5bcd97fa06c0d183e633494eca6aa61908348ae Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* Add tst_qquickflickable::nestedSliderUsingTouchShawn Rutledge2017-03-271-0/+161
| | | | | | | | | | | to verify that when a touch-handling component is inside the Flickable, it can control whether the flickable can steal the grab by means of setKeepTouchGrab. Task-number: QTBUG-59416 Task-number: QTBUG-59707 Change-Id: I93cf3abb07a96a69290c3b5b055b688a62fe8fff Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* tst_qquickflickable: clean up touch event handlingShawn Rutledge2017-03-271-17/+9
| | | | | | | | Use QTest::createTouchDevice now that it exists. No need for each test to create a device and pass it in to flickWithTouch Change-Id: I81131a13aaba01cfa0f04b25f334c80263625d12 Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
* Merge remote-tracking branch 'origin/5.8' into 5.9Liang Qi2017-02-241-0/+20
|\ | | | | | | | | | | | | | | | | | | | | Conflicts: src/qml/compiler/qv4ssa.cpp src/quick/accessible/qaccessiblequickview_p.h src/quick/items/qquickmousearea.cpp src/quick/util/qquickanimatorjob.cpp tools/qmlplugindump/main.cpp Change-Id: I84474cf39895b9b757403971d2e9196e8c9d1809
| * Flickable: handle child mouse ungrab when hidden or disabledJ-P Nurmi2017-02-081-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | If Flickable got hidden while a child had mouse grab, it ignored the mouse ungrab event of the child mouse grabber, and got therefore stuck in pressed state. Consequently, item view transitions were not executed since the item view though it was being pressed. Task-number: QTBUG-58453 Change-Id: I76f9f3190c3a95a2fafdce036d69ea1dc8127434 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-07 06:50:27 +0000