aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquickflickable.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Flickable: ignore trackpad events with px deltas in disallowed directionShawn Rutledge2021-01-151-5/+18
| | | | | | | | | | | | | | | | 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>
* Kill Flickable's wheel momentum if angleDeltas not multiples of 120Shawn Rutledge2020-12-071-34/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wheel momentum is great on old "clicky" mouse wheels: they feel really clunky without this feature. But it's also terrible on most laptop touchpads. We still aren't generating QWheelEvents with pixel deltas and ScrollPhase on most platforms (still only on macOS); but eventually we should. However, those laptop touchpads tend to generate angleDeltas that are not multiples of 120. Added logging categories qt.quick.flickable qt.quick.flickable.wheel and qt.quick.flickable.velocity. [ChangeLog][QtQuick][Flickable] Flickable now tries to detect whether you're using a "clicky" wheel on a desktop mouse. A laptop trackpad can generate QWheelEvent::angleDelta values that are not multiples of 120; in that case, smooth scrolling with momentum is disabled, to avoid losing control of scrolling. Set the environment variable QT_QUICK_FLICKABLE_WHEEL_MOMENTUM_ENABLED=0 to opt out of the old behavior entirely, or set it to 1 to opt in unconditionally. Pick-to: 6.0 Task-number: QTBUG-38570 Task-number: QTBUG-56075 Task-number: QTBUG-80720 Task-number: QTBUG-82565 Change-Id: I0da2d31259fa1c79ab217a3fa9e888893fc7b235 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Make sure we don't modify the incoming event objects when localizingVolker Hilsheimer2020-11-191-3/+6
| | | | | | | | | | | Restore the position of the single event point after event delivery. Where possible, don't make a localized copy which explicitly shares its data with the original anyway. Instead, access the original directly. Change-Id: I5efa44c336eddeef1a1ab00dc91e2d0f223ed31d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Use QMutable*Event classes to copy and synthesize eventsVolker Hilsheimer2020-11-181-4/+3
| | | | | | | | | | QMutableTouch/SinglePointEvent can be publicly copy constructed from their non-mutable counterparts, make use of that. Change-Id: I7f56a9f9649bb7726cca1eaddccfdc3f21d47554 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* When Flickable filters UngrabMouse, react as if it was ungrabbed itselfShawn Rutledge2020-11-171-5/+8
| | | | | | | | | | | | | | | | | | | | | Fixes tst_QQuickListView::touchCancel again. In this scenario, a TouchCancel is sent, but gets turned into an UngrabMouse for delivery to the MouseArea which is the current grabber. We try to avoid calling QQuickWindow::mouseGrabberItem() because it's too vague a question to ask (which mouse? or did you mean the synth-mouse during synthesis from a touch or tablet event?); and now it acts different anyway, because eventsInDelivery.top() is an UngrabMouse, which did not include a pointer to the QPointingDevice until now. So now we turn the UngrabMouse event into a QSinglePointEvent so that it's possible to get exclusiveGrabber() and check that the grabber is not the same Flickable. (Otherwise, the grabber that's getting ungrabbed is usually the child receiver item sent to childMouseEventFilter().) Task-number: QTBUG-86729 Task-number: QTBUG-74679 Change-Id: I6dfd96686bdfb54723bbe093406b6ab1f75de855 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Don't synthesize mouse from touch for items that accept touchShawn Rutledge2020-11-171-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Teach flickable to handle and replay touch as it does mouseShawn Rutledge2020-11-111-74/+149
| | | | | | | | | | | | | | | | | | | | | | | | | | | | QQuickWindowPrivate::cloneMouseEvent() renamed to clonePointerEvent() and generalized to be able to clone any of the kinds of QPointerEvent that we're interested in replaying. Now it is used only in QQuickFlickablePrivate::captureDelayedPress(). Reverts f278bb7c66bb00c9f81b7a3aceeb94cb9b3a1b66 and 012a4528a515af8d7ec7dbc05a38d8fd0d6d4d1b (don't skip tst_TouchMouse::buttonOnDelayedPressFlickable). Some test changes from f128b5dee8a2a03ebc55ed0cd1e749a6599282c3 also get reverted. QEventPoint should always have valid velocity now, so Flickable no longer has to calculate it for itself. Removing that became necessary to fix the movingAndFlicking test. Adds logging categories qt.quick.flickable.filter and .replay. Fixes: QTBUG-85607 Task-number: QTBUG-83437 Task-number: QTBUG-78818 Task-number: QTBUG-61144 Task-number: QTBUG-88038 Task-number: QTBUG-88138 Change-Id: I0ed6802dff5e5d1595adddc389642925f1f2c93d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QQmlListProperty: Use qsizetype rather than int for sizesUlf Hermann2020-11-091-2/+2
| | | | | | | | | | [ChangeLog][QtQml] The QQmlListProperty callback functions use qsizetype now as type for the size of a list. This is in line with the containers that you might use to back the list. Fixes: QTBUG-88269 Change-Id: Ia38403cb32f241e6c70e1a580dbeff1d6d694331 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQuickFlickable::filterPointerEvent(): remove handling of receiver==thisShawn Rutledge2020-10-211-7/+1
| | | | | | | | | | | Since the Q_ASSERT_X(receiver != this, ...) has been there for a long time, clearly it never happens in real life. It doesn't happen in any of our autotests either. So having dead code to handle it is just confusing. Amends d9d2277fb8e823af8977d6f3aa5cc7ee8213c26a Change-Id: I69714804e4967cc1a373af67bf4c9a4c169f5738 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Don't assume the event given to childMouseEventFilter() is QPointerEventShawn Rutledge2020-10-081-2/+2
| | | | | | | | | | It can also be an UngrabMouse event, a plain QEvent, sent from QQuickWindowPrivate::onGrabChanged(). So we have to test isPointerEvent() before casting, rather than asserting beforehand. Amends 9ce346411eb5bd71ae84647999030ae47c3c544a to fix a crash. Change-Id: I1d169b4e8c8a58f3736a3d95dfc43fa21e123403 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Amend QQFlickablePrivate::wantsPointerEvent() to take QPointerEventShawn Rutledge2020-10-081-1/+2
| | | | | | | | | | ...now that we're done with the cherry-pick to 5.15. Amends 6857ad3e686a5e2b45d28a7f47dca3210608da50. Task-number: QTBUG-74046 Task-number: QTBUG-85302 Change-Id: I3c2ec091976bcfc170ff58d8fcd226dcdf4c90d2 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickListView: prevent mouse delivery in floating header or footerShawn Rutledge2020-10-071-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Earlier we reimplemented the contains() method of ListView to prevent dragging in an Overlay or Pullback header or footer. But in QQuickWindow (QQuickWindowPrivate::pointerTargets()), an early check prevents delivery of pointer events to an item that is clipped and for which contains() returns false, and also to its children. In that case, the header or footer no longer responds to a mouse event even if you put a MouseArea in it. Reverts 6ad3445f1e159d9beea936b66d267dcaacdc5d6c; reimplemented using similar logic in a new QQuickListViewPrivate::wantsPointerEvent() method, overriding QQuickFlickablePrivate::wantsPointerEvent(), which is now checked in event-handling code in addition to checking the interactive flag. Done-with: Wang Chuan <ouchuanm@outlook.com> Pick-to: 5.15 Task-number: QTBUG-74046 Fixes: QTBUG-85302 Change-Id: I9474f035d26b74ee36c0ac19e45a77de2e694bf1 Reviewed-by: Wang Chuan <ouchuanm@outlook.com> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Remove QQuickPointerEvent etc.; deliver QPointerEvents directlyShawn Rutledge2020-09-181-13/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Keep replaying touch press as mouse press after Flickable.pressDelayShawn Rutledge2020-07-151-1/+13
| | | | | | | | | | | | In the future, if QQuickFlickable has pressDelay set, and receives a touch event, we want it to replay the touch after the delay. But in Qt 5 it can only replay a delayed mouse press, and hacks are in place to deal with that. We aren't ready to change it all just yet, and need to keep the autotest working as-is for now. Task-number: QTBUG-78818 Change-Id: Ib37ccfc2b1b84254f40acac8f8ca8c51c9a88ddf Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Begin handling the QEvent refactoringShawn Rutledge2020-07-151-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | This is an intermediate step to get Qt Quick working again after qtbase 4e400369c08db251cd489fec1229398c224d02b4. - QQuickEventPoint::id() is no longer unique across devices, because now eventPoint.event.device tells which specific device the event comes from. (In Qt 5, we could not yet add the device pointer to QInputEvent.) - However, MultiPointTouchArea's docs say that each pointId is unique, and so do the HandlerPoint docs (for similar use cases with PointHandler). So we still need the same hack using a Qt-specific short device ID to unique-ify the QEventPoint::id(). Now we use the device index in QInputDevice::devices() as the short ID. - Otherwise, we trust QInputDevice::systemId() and QEventPoint::id() more than before. - Use QMutable* classes from qevent_p.h to continue using setters that were in QTouchEvent before, etc. But setTouchPoints() is not there, so we have to make new event instances in a couple of cases. - QGuiApplicationPrivate::setMouseEventCapsAndVelocity() and setMouseEventSource() are gone. - Use (compiler-written) event copy constructors when possible. Task-number: QTBUG-72173 Change-Id: I3915dc535ae4c5a81cbf333aba9355f01c420c15 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Remove QQuickPointerDevice in favor of QPointingDeviceShawn Rutledge2020-06-231-3/+4
| | | | | | | | | | | | | | ...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-8/+8
| | | | | | | | | | | | | | | | | | | | 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>
* Consider margins in xflick/yflickNicolas Fella2020-05-251-4/+6
| | | | | | | | | | | | | | AutoFlickDirection and AutoFlickIfNeeded compare the size of the flickable with the size of the content item. We need to take margins into account since they might cause the need for scrolling when the content would otherwise fit. Fixes: QTBUG-31905 Pick-to: 5.15 Change-Id: I18d073af4c6ffb1b703f5e2b33f616b61e816e56 Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Marco Martin <mart@kde.org> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Respect margins when sizing flickable content itemNicolas Fella2020-05-151-4/+4
| | | | | | | | | | | | | | | When setting the width/height of the content item we need to take the margins into account. Otherwise for example a left margin of 10 causes the content item to exceed the parent by 10 pixels to the right. This causes, amongst possibly other issues, misaligned headers/footers. Pick-to: 5.15 Change-Id: Ib620bb3be4a4f620b61f14564beb92ceb10ab02f Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Marco Martin <mart@kde.org> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickItem: rename geometryChanged to geometryChangeMitch Curtis2020-04-231-3/+2
| | | | | | | | | | | | | | | | | | This brings it in line with the existing convention in this and other modules, where virtual handlers are named "nounChange"; e.g. itemChange. Signals are named "nounChanged". This also allows adding a geometryChanged signal, which would enable users to listen to one signal for all changes to x/y/width/height. [ChangeLog][QQuickItem] Renamed geometryChanged to geometryChange in order to follow existing naming conventions and have consistency with existing API, such as itemChange. Task-number: QTBUG-82994 Change-Id: I0547358c796a0047982ccfbf2c38bab952e7a634 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-03-281-0/+3
|\ | | | | | | Change-Id: If7b3f7902eb18d586d8b721e77f4dfedc87cfb9a
| * Flickable: add nullptr check (crash seen only in release mode on windows)Nick Shaforostov2020-03-261-0/+3
| | | | | | | | | | Change-Id: I2ac42ded0c2ed4dc3937a57f69109f10b19f9cc7 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Remove hard-coded notes for 'Corresponding handler' for QML signalsTopi Reinio2020-03-101-12/+0
| | | | | | | | | | | | | | | | QDoc will generate these notes automatically. Task-number: QTBUG-37355 Change-Id: I8ed058ecbbcc630ad0351f6ce167c3fa61936f6f Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-02-061-4/+15
|\| | | | | | | | | | | | | | | | | | | 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-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Avoid initializing QFlags with 0 or nullptr in further casesFriedemann Kleint2019-11-251-1/+1
|/ | | | | | | Amends 744e77b841878fb017c0f2d60607090008f28180. Change-Id: I16e37aaf503eb62f67fca0e48be4c92c4a72ae46 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Fix qmlobject_{dis}connect macros to require semicolon at the endJan Arve Sæther2019-09-161-2/+2
| | | | | | | | | | | | | | | | | | Just do the typical do { [..stuff..] } while(0) in the macros Fix the places that didn't have semicolons. This should eliminate some compiler warnings complaining about excessive semicolons Change-Id: I6b0e7a55badfd0f80c3cd0e9e1da42dc41945485 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Remove usages of deprecated APIs of QWheelEventSona Kurazyan2019-08-231-2/+3
| | | | | | Task-number: QTBUG-76491 Change-Id: I69b0c4ec7c03f9421b18828516e064eff2b45518 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix crash caused by objects self-destructions during displacement animationsYulong Bai2019-06-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The root cause was that the QAbstractAnimationJob::finished() might delegate its destruction to change.listener->animationFinished(this), and the original author was aware of that and provided a RETURN_IF_DELETE macro to return early if itself got deleted. In the bug's case, change.listener->animationFinished(this) dispatched to QQuickItemViewPrivate::animationFinished() which called QQuickItemViewPrivate::release() and deleted the QAbstractAnimationJob object itself in the end. However, any objects derived from QAbstractAnimationJob, or holding a pointer to a QAbstractAnimationJob, may potentially fall into the code path calling QAbstractAnimationJob::finished(). Any QAnimationJobChangeListener that directly or indirectly deletes QAbstractAnimationJob should be very suspicious to this kind of "heap-use-after-free" bug. Should ensure that the QAbstractAnimationJob won't be referenced after deletion. In the bug's case, within the code path triggered by ListView displacement animation, the other affected classes by QAbstractAnimationJob are: QQuickItemViewFxItem, QQuickItemViewTransitionableItem, QQuickTransitionManager. To fix this, a new SelfDeletable class is factored out to simplify the self-deletion test logic. Any affected classes are made to have a public member m_selfDeletable. Any code paths that finally reach QAbstractAnimationJob::finished() are wrapped with related util macro. Change-Id: Idd33fc3f2d529fd7d8bb088c329101b1e70dd6c0 Task-number: QTBUG-44308 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickFlickable: fix setContentX/setContentY comparing qrealYulong Bai2019-03-011-2/+2
| | | | | | | | | QQuickFlickable::setContentX/setContentY used !=/== to compare qreal, which would trigger binding loop warnings while using bi-directional property bindings. Fixes: QTBUG-74128 Change-Id: I224a924e11c93cf047478ba0e09e10e57eedabde Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Add handlers declared as Flickable children to its contentItemShawn Rutledge2019-01-221-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Prevent ListView from jumping horizontally with flick(0,<number>)Michael Brasser2018-08-231-2/+2
| | | | | | | | The internal flick functions were not written to handle empty flicks in invalid directions. Guard our calls accordingly. Change-Id: I34801a7e548160ce4895dd8a2f6c0b17172cd02e Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Flickable: handle the new ScrollMomentum phase in QWheelEventShawn Rutledge2018-08-221-29/+18
| | | | | | | | | | | | | | Now we can tell when macOS is sending wheel events that represent simulated momentum, and Qt::ScrollEnd is guaranteed to mean that scrolling actually ended. So the timer to check whether it really ended is no longer necessary. This reverts commit 87a4d4babe0a3d6b8a57048205eccc7105931474. Task-number: QTBUG-63026 Task-number: QTBUG-65160 Change-Id: I0988e934b43989a3501b89d0a77eee616328ece2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QQuickFlickable: add a default for new added Qt::ScrollMomentumLiang Qi2018-08-201-0/+2
| | | | | | | which was added in qtbase e09f5b17. Change-Id: Id16ba131ac8a92beccaecb52a1e73627557a4939 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Increase fine-grained signals for some properties in FlickableAleix Pol2018-07-311-6/+15
| | | | | | | | | | | | 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>
* Flickable: never react to a QMouseEvent with no buttons pressedShawn Rutledge2018-07-261-1/+1
| | | | | | | | | | | | If a Flickable contains an Item with a HoverHandler and a DragHandler, and you drag it and release it, then during the next mouse move events, since Flickable is able to filter those while they are being sent to the HoverHandler, it would grab the mouse. Suddenly you'd be flicking even with no mouse buttons pressed. I think I've seen similar behavior in other scenarios too, at some point. Change-Id: If79c8af2b62dc69f085513e0b7c8bf9b4d504572 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Merge remote-tracking branch 'origin/5.11' into devQt Forward Merge Bot2018-07-161-1/+26
|\ | | | | | | | | | | | | | | Conflicts: src/quick/items/qquickloader.cpp tests/auto/quick/qquickanimations/tst_qquickanimations.cpp Change-Id: I0cb9f637d24ccd0ecfb50c455cc210119f744b02
| * Doc: add a section that demonstrates various contentX/contentY statesMitch Curtis2018-07-041-1/+26
| | | | | | | | | | | | | | This makes it easier to visualize how the properties work. Change-Id: I04cb1a99a1f831e5c892cb27e4a0cd127fe450e0 Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* | Add Flickable.synchronousDrag propertyShawn Rutledge2018-07-121-2/+30
|/ | | | | | | | | | | | | | | 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>
* Doc: Add missing dots (qtdeclarative)Paul Wicking2018-06-191-1/+1
| | | | | | Task-number: QTBUG-68933 Change-Id: Ibb5aa227e82825085e7214e17dcffcb17fd44157 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Flickable: fix another possible cause for out-of-sync moving flagsNils Jeisecke2018-06-191-4/+2
| | | | | | | | | | | | | | | | | | In addition to d868bb4f3e4b0424fd4a2989ff1c82692b0f014c this removes the check for scrollingPhase in movementEnding. If movementEnding is invoked by some codepath other than timerEvent (e.g. setContentY) and scrollingPhase is true this will again prevent any further invocation of movementStarting from within the drag method (see d868bb4). As this check was introduced together with the movementEnding timer (QTBUG-63026) and scrollingPhase is now checked inside the timerEvent there should be no need for the check in movementEnding. Task-number: QTBUG-67460 Change-Id: I88ad6e3ee56b88a66bb61798b8876324f4842f1e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix Flickable mouse wheel handling on macOSNils Jeisecke2018-04-061-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On macOS a special movementEnding timer was added to the wheelEvent handling to fix QTBUG-63026. This has introduced a regression with wrong vData/hData.moving flags: When the timer fires before the Qt::ScrollEnd phase is reached, movementEnding is invoked early (can be reproduced with very slow scrolling using the Magic Mouse). In this case movementEnding sets vData.moving = false but not vMoved = false because scrollingPhase is still true. This will prevent any further invocation of movementStarting from inside the drag method (it expects a change in vMoved) so once this situation has occurred the "moving" flags will be out of sync. Visible effect: If a ListView has a currentItem set with setCurrentIndex, its viewportMoved method will no longer correctly set the moveReason to "Mouse" because the check depends on "moving" flag as an indicator for mouse interaction. This results in the view permanently jumping back to the current item on any scroll operation because the moveReason will be stuck at "SetIndex". The fix is to ignore the timer event if scrollingPhase is still true. Task-number: QTBUG-67460 Change-Id: I7cf02b8c625b7baf249ad26c4e0c3df874a18eae Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* use nullptr consistently (clang-tidy)Shawn Rutledge2018-02-261-9/+9
| | | | | | | | | | | | | 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.10' into devLiang Qi2018-02-021-3/+11
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/plugins/qmltooling/qmldbg_profiler/qqmlprofilerservice.cpp src/qml/compiler/qqmlirbuilder.cpp src/qml/compiler/qqmlirbuilder_p.h src/qml/compiler/qqmltypecompiler.cpp src/qml/compiler/qv4codegen.cpp src/qml/compiler/qv4codegen_p.h src/qml/compiler/qv4compileddata_p.h src/qml/compiler/qv4compiler.cpp src/qml/compiler/qv4compilercontext_p.h src/qml/compiler/qv4isel_moth.cpp src/qml/compiler/qv4jsir.cpp src/qml/compiler/qv4jsir_p.h src/qml/jit/qv4isel_masm.cpp src/qml/jsruntime/qv4engine.cpp src/qml/jsruntime/qv4functionobject.cpp src/qml/jsruntime/qv4runtimecodegen.cpp src/qml/jsruntime/qv4script.cpp src/qml/jsruntime/qv4script_p.h src/qml/qml/qqmltypeloader.cpp src/quick/items/qquickanimatedimage.cpp src/quick/items/qquickanimatedimage_p_p.h src/quick/scenegraph/compressedtexture/qsgpkmhandler.cpp tests/auto/qml/qmlplugindump/qmlplugindump.pro tests/auto/qml/qmlplugindump/tst_qmlplugindump.cpp tools/qmlcachegen/qmlcachegen.cpp tools/qmljs/qmljs.cpp Done-with: Shawn Rutledge <shawn.rutledge@qt.io> Done-with: Lars Knoll <lars.knoll@qt.io> Done-with: Ulf Hermann <ulf.hermann@qt.io> Change-Id: I010e6525440a85f3b9a10bb9083f8e4352751b1d
| * Merge remote-tracking branch 'origin/5.9' into 5.10Liang Qi2018-01-241-3/+11
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/qml/compiler/qv4codegen.cpp src/qml/compiler/qv4compileddata_p.h src/qml/debugger/qqmlprofiler_p.h src/qml/jsruntime/qv4engine.cpp src/qml/memory/qv4mm.cpp src/qml/qml/qqmlcomponent.cpp src/qml/qml/qqmlobjectcreator.cpp src/qml/qml/qqmlobjectcreator_p.h src/qml/types/qqmldelegatemodel.cpp src/quick/items/qquickitem_p.h src/quick/items/qquickwindow.cpp tests/auto/quick/touchmouse/BLACKLIST tests/benchmarks/qml/holistic/tst_holistic.cpp Change-Id: I520f349ab4b048dd337d9647113564fc257865c2
| | * Flickable: don't jump after premature movementEnding due to timerShawn Rutledge2017-12-131-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Followup to ef8c6f6a0bf5e4c9ee41306f2df59048ab96038f: we emit movementEnding for the benefit of the user, scrollbars, decorators etc. in case the ScrollEnd phase means that movement really ended (it means the user lifted his fingers from the trackpad, but momentum events can cause the movement to continue after that). But in case movement didn't end, we don't want to have a jump when it resumes. But scrollingPhase will be true after an event with ScrollBegin phase, and false after an event with ScrollEnd, also false if the mouse is an ordinary wheel mouse without phases. So when the timer fires, if the user has not yet lifted his fingers, scrollingPhase is true, and that means scrolling isn't really ending, so we should not set vMoved to false. Setting vMoved to false will cause the drag() function to reset vData.dragStartOffset to the current dy value, which ultimately causes the jump in contentY. It should be done only when scrolling really ends. If the timer fires and scrollingPhase is false, we can be sure it really ended. But if you flick, then rest your fingers, then lift them, there is no momentum, so the final event has scroll phase ScrollEnd, and we need to run the timer one more time to detect that there are no more updates and finish the transition back to the default state (set vMoved back to false, emit signals such as movementEnded, etc.) The ultimate solution is to add another Qt::ScrollPhase enum, such as ScrollMomentum, but we should not do that in the 5.9 series. Task-number: QTBUG-63026 Change-Id: I854c52a680028cb1d43b133be65653d87a05a0b1 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | | Merge remote-tracking branch 'origin/5.10' into devLiang Qi2017-12-201-20/+36
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.10Shawn Rutledge2017-11-131-1/+15
| |\| | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/quick/items/qquickwindow.cpp src/quick/items/qquickwindow_p.h tests/auto/quick/quick.pro Change-Id: Ia12f20e95fb151bbbc75dbf187364a924cd0bc7a
| | * docs and example: clarify the usage of Flickable contentX/contentYShawn Rutledge2017-11-081-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's such a common mistake to observe that they normally go to zero at the top-left corner, but fail to realize that they won't always do that. Task-number: QTBUG-64219 Task-number: QTBUG-22894 Task-number: QTBUG-27884 Change-Id: I6bc81d4761debdaff8fb3366bf1e944241207157 Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
| * | Merge remote-tracking branch 'origin/5.9' into 5.10v5.10.0-beta4Liang Qi2017-11-061-19/+21
| |\| | | | | | | | | | Change-Id: I8ede7e36592cd21f3e4a0a9b30dbe26bb40fe69b