aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/qquickflickable
Commit message (Collapse)AuthorAgeFilesLines
* Flickable: prevent fixup() from being called while draggingOliver Eftevaag2022-12-201-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>
* Revert "Blacklist 1 tests in tst_qquickflickable on macos"Jan Arve Sæther2022-12-161-3/+0
| | | | | | | | | This reverts commit c6d8d037828701622d5664b5141e1ffe18065097. Reason for revert: CI Insignificant Platforms Monitor Bot erroneously thought that setContentPositionWhileDragging() was failing: (see https://bugreports.qt.io/browse/QTBUG-106278) Change-Id: I24c644c24b9cddcd348a87a2c486dc5d7c126ce8 Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
* Blacklist 1 tests in tst_qquickflickable on macosCI Insignificant Platforms Monitor Bot2022-09-151-0/+3
| | | | | | | | - setContentPositionWhileDragging Task-number: QTBUG-106278 Change-Id: I572c34aaf632929a81bb2ba8afa4d7549ed5355b Reviewed-by: CI Insignificant Platforms Monitor Bot <ci_insignificant_platforms_monitor_bot@qt.io>
* Flickable: let changing contentItem pos also affect the drag starting posOliver Eftevaag2022-09-082-1/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Fix Flickable wheel velocity calculationShawn Rutledge2021-12-041-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 Change-Id: I5166ca31c86335641cf407a922a3a970fced653d (cherry picked from commit a8fbd865140d4dd165723c7e3d4168514d4b1d0c) Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-02-062-0/+49
|\ | | | | | | | | | | | | | | | | | | 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-292-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-072-4/+4
|/ | | | | 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>
* Un-blacklist tst_qquickflickable::reboundShawn Rutledge2019-02-101-3/+0
| | | | | | Fixes: QTBUG-26696 Change-Id: I32cebc9e0b63b55113f24fd40c06e7017b763aaf Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Remove blacklisting of several tests that are passingShawn Rutledge2019-02-101-4/+0
| | | | | | | | | | | | | ...based on statistics visible in Grafana. Task-number: QTBUG-41895 Task-number: QTBUG-38209 Task-number: QTBUG-65978 Task-number: QTBUG-36804 Task-number: QTBUG-45466 Task-number: QTBUG-29062 Change-Id: If62d2413ede234d33b411e0ecb4f93ec6e0f8062 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Stabilize nestedSliderUsingTouch:keepNeither test on UbuntuShawn Rutledge2018-09-132-20/+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>
* Blacklist tst_qquickflickable::nestedSliderUsingTouchJoni Jantti2018-07-121-0/+1
| | | | | | | | This autotest fails on Ubuntu 18.04 builds. Task-number: QTBUG-68867 Change-Id: Id4a9f15cc686c367406e1f12c7477688c7bc5304 Reviewed-by: Tony Sarajärvi <tony.sarajarvi@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-202-0/+9
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | blacklist tst_qquickflickable::rebound on macOSv5.10.0-rc1Shawn Rutledge2017-11-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | It's not only on 10.10 Task-number: QTBUG-26696 Task-number: QTBUG-36804 Change-Id: I6652cc3c32cc0219e58f7bf6d9584e3041ad34e8 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
| * | 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>
* | | tst_qquickflickable::rebound() also fails on macOS 10.11Lars Knoll2017-10-231-1/+1
|/ / | | | | | | | | | | Change-Id: I4163f6f2938d12b04b143ae0b3004a0c08183735 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Erik Verbruggen <erik.verbruggen@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>
* | Merge remote-tracking branch 'origin/dev' into wip/pointerhandlerShawn Rutledge2017-04-133-66/+300
|\ \ | | | | | | | | | Change-Id: Ie2894830470a69827d4ace3d8af9bee971e3fbd4
| * | 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>
| * Blacklist nestedSliderUsingTouch in Ubuntu 16.04Tony Sarajärvi2017-04-041-0/+2
| | | | | | | | | | | | Task-number: QTBUG-59840 Change-Id: I147eb4aa0f0c61f9c017ce1614ea3b2b2d2386c9 Reviewed-by: Liang Qi <liang.qi@qt.io>
| * Add tst_qquickflickable::nestedSliderUsingTouchShawn Rutledge2017-03-272-0/+197
| | | | | | | | | | | | | | | | | | | | | | 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/dev' into wip/pointerhandlerShawn Rutledge2017-03-022-0/+33
|\| | | | | | | Change-Id: I7e43a0a47d49de38617f6afc7548f9a9e212a851
| * Merge remote-tracking branch 'origin/5.8' into 5.9Liang Qi2017-02-242-0/+33
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-082-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | build a vector of child-filtering parents before delivery of pointer eventShawn Rutledge2017-01-271-0/+3
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Formerly during normal mouse or touch event delivery, sending it to the Item needed to be done via QQuickWindow::sendEvent, which would then call sendFilteredMouseEvent, which is a recursive function to visit all the item's parents, check whether filtersChildMouseEvents() returns true, if so then return early if childMouseEventFilter() returns true. This is the mechanism by which Flickable (for example) can monitor the movements of an eventpoint even while one of its children has an exclusive grab, and can steal the grab away. Now, we do this by building a vector of such parents first, then visiting them in order. It might be more efficient, it eliminates the recursion, and should eliminate the need for a QSet to ensure that we don't visit the same parent more than once. We can't change the behavior of QQuickWindow::sendEvent() because it's public API, but now we don't use it as much internally. Change-Id: I686fc5612c66eac09ec05c381a648ec65dec3923 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* / Flickable: add horizontal/verticalOvershoot propertiesJ-P Nurmi2016-12-293-0/+330
|/ | | | | | | | | | [ChangeLog][QtQuick][Flickable] Added horizontalOvershoot and verticalOvershoot properties that can be used for implementing boundary actions and effects. Task-number: QTBUG-38515 Change-Id: I06379348a67d03507b56788d6fc7020bbb2d375f Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
* Get rid of most QT_NO_FOO usagesLars Knoll2016-11-291-1/+1
| | | | | | | | Instead use QT_CONFIG(foo). This change actually detected a few mis-spelled macros and invalid usages. Change-Id: I06ac327098dd1a458e6bc379d637b8e2dac52f85 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Merge remote-tracking branch 'origin/5.7' into 5.8Liang Qi2016-10-103-18/+153
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: examples/quick/quickwidgets/quickwidget/main.cpp src/qml/jsruntime/qv4jsonobject.cpp src/qml/jsruntime/qv4qobjectwrapper.cpp src/qml/jsruntime/qv4qobjectwrapper_p.h src/qml/qml/qqmlengine.cpp src/qml/qml/qqmlpropertycache.cpp src/qml/qml/qqmlpropertycache_p.h src/quick/items/qquickanimatedsprite.cpp src/quick/items/qquickitem.cpp src/quick/items/qquickitem.h src/quick/items/qquickitem_p.h src/quick/items/qquickview_p.h src/quick/scenegraph/qsgcontext.cpp src/quick/scenegraph/qsgdefaultrendercontext.cpp Change-Id: I172c6fbff97208f21ed4c8b6db3d1747a889f22b
| * Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-10-051-0/+45
| |\ | | | | | | | | | Change-Id: I081d9b15796b4133d2ba6f1a862f15b873a4846d
| | * Flickable: add a trackpad (touchpad) autotestShawn Rutledge2016-10-041-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've had this feature for a long time, to use pixel deltas and scroll phase effectively, but no autotest until now. It's still not very thorough but it's a start. Task-number: QTBUG-55871 Change-Id: Iaf6e7a842ce90828da3253e8673cac9905abd046 Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
| * | Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-09-302-1/+24
| |\| | | | | | | | | | | | | | | | | | | Conflicts: tests/auto/quick/qquicktext/tst_qquicktext.cpp Change-Id: I241cd418bb7e7b95e0a0a2ee4c465d48be2a5582
| | * Flickable: do not emit movementEnded until it really doesShawn Rutledge2016-09-292-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was occurring when using a physical mouse wheel: movementEnded was emitted, then contentYChanged would still be emitted a few more times. Task-number: QTBUG-55886 Change-Id: Ib5e833d5d84633bb07b8c240ea3ccc9977e443f8 Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
| * | Fix Flickable state being reset when it replays a delayed press.Andrew den Exter2016-09-232-17/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | Ignore mouseUngrabEvents() triggered by giving mouse grab to a child item when replaying a delayed press event. Change-Id: I6c8db61167e21bf10d533b17f7cc65e4754bd432 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Martin Jones <martin.jones@qinetic.com.au>
| * | autotests: remove qWait(1) in touch sequencesShawn Rutledge2016-08-131-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After d04982dc84d66bec92b4b3767538676cf925ef17 in qtbase, QTest::touchEvent() and QTouchEventSequence::commit() slow down every sequence of touch events, so we don't need to do it in individual tests. Change-Id: Id8133b100797d4bd2d7282ee874dbb81ed2cab47 Reviewed-by: Liang Qi <liang.qi@qt.io>
| * | Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-08-131-0/+1
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/qml/compiler/qv4isel_moth.cpp src/qml/compiler/qv4ssa_p.h tests/benchmarks/qml/qqmlimage/qqmlimage.pro tests/benchmarks/qml/qqmlimage/tst_qqmlimage.cpp Change-Id: Iad11ce7fdf0c6d200fdebc16a94081bd8069a87a
| | * Flickable: avoid infinite velocity during release after dragShawn Rutledge2016-08-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It sometimes happens on touchscreens that mouse events occur too close together. We cannot calculate velocity based on zero elapsed time, so just ignore the event. Task-number: QTBUG-45527 Change-Id: I120e73cfa60e2fcc594cb1f3b69f530e746abddd Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-29 11:06:30 +0000