aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquickwindow_p.h
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Update commercial license headers"v5.15.3-lts-lgplTarja Sundqvist2021-03-241-20/+20
| | | | | | | | | | | This reverts commit 7b1331c789df0ac12d7cf5aa5f8967b8651a4cfa. Revert of commercial license headers is required for Qt 5.15.3 opensource release. Task-number: QTBUG-91108 Change-Id: I47eb004523bdb3beb16e9fd51e40da6f738f9f34 Reviewed-by: Jukka Jokiniva <jukka.jokiniva@qt.io>
* Update commercial license headersTarja Sundqvist2021-02-021-20/+20
| | | | | | | | | | | | | | | Updated header.COMM to the files in tqtc-qtdeclarative. Examples, documentation files or tests are not updated. The commercial license header may contain some additional lines so that its line count equals with the earlier license header. Reason for this is that some autotests use hard coded line numbers and a change in the line count causes failures in tests. Task-number: QTQAINFRA-4161 Change-Id: Ic1d011aa01b1fe7242bcbbf72d5ab454d1015cf9 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Export QQuickRootItem to QMLUlf Hermann2020-02-251-1/+1
| | | | | | | It was exported in 5.14, so we should probably still do so. Change-Id: Id44783c72fff50aee63d7c5a72f12ff9ca895a6b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Use the extended QQmlListProperty interface in a few placesUlf Hermann2020-02-071-0/+2
| | | | | | | Task-number: QTBUG-79263 Change-Id: If518f644b5b9eddbacfb1cb16fbb557127ffcfb2 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add PointerHandler.cursorShape propertyShawn Rutledge2020-01-311-1/+2
| | | | | | | | | | | | | | | | | | Also, QQuickItemPrivate::setHasCursorInChild() was unable to check the QQuickItemPrivate::hasCursor variable, because the function argument hasCursor was shadowing that, even though the comment "nope! sorry, I have a cursor myself" hints that the intention was to check that. So this change exposed a problem there, and we have to fix that too, in order to keep the tst_qquickwindow::cursor() test passing. [ChangeLog][Event Handlers] Pointer Handlers now have a cursorShape property to set the cursor when the handler is active and the mouse is hovering, and restore to the previous cursor when the mouse leaves. Fixes: QTBUG-68073 Change-Id: Ib5c66bd59c4691c4210ee5465e1c95e7bdcf5ae1 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Make the initialization failure dialog sensible with QRhiLaszlo Agocs2019-11-281-2/+4
| | | | | | | | | | | | | | | So on Windows one now gets a message box with a reasonable message, instead of the OpenGL nonsense. Then the application closes when pressing Abort etc. On other platforms there is a qFatal, printing the same message. Involves simplifying the OpenGL version a bit since passing isES type of flags through multiple layers is not justified here. Task-number: QTBUG-80365 Change-Id: Ie3ea1e9395a283f7e95eda78c1d3894797ff0acf Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* Prevent infinite rhi init failure in threaded render loopLaszlo Agocs2019-11-281-1/+2
| | | | | | Task-number: QTBUG-80365 Change-Id: I929fb76eb8d023ab048f6d1c91be078de3cfe750 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Avoid initializing QFlags with 0 or nullptrAllan Sandfeld Jensen2019-11-221-2/+2
| | | | | | | | | It is being deprecated. Change-Id: I844bd92af85bc53a8fc0371408d05277bd49f511 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-10-101-1/+1
|\ | | | | | | Change-Id: I2835748c27616103f275849141fbe5a93e3dfd8c
| * QQuickWindow: Higher z-order items now steal drop targetStephen D'Angelo2019-10-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, an active drop target would remain the drop target until the drag left it's area, or entered a child item that accepted a DragEnterEvent, even if the drag entered a drop target with a globally higher z-order from a different subtree. When moving to an item with a higher z-order, the DragEnterEvent is now sent to the new drop target before DragLeaveEvent is sent to the old drop target. There can now only be one drop target. If an item is the current drop target and a higher z-order child accepts the DragEnterEvent, the parent is no longer a drop target. Fixes: QTBUG-30305 Change-Id: I7b985d6317be70867e7727222a4cd44ace7559e6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-10-041-1/+1
|\| | | | | | | | | | | | | | | Conflicts: src/imports/qtquick2/plugins.qmltypes src/quick/items/qquickitemsmodule.cpp Change-Id: I841c65c9c131354788b4f3fcfe3d7ed27be316d5
| * QQuickWindow: Don't leak the animation controllerUlf Hermann2019-10-021-1/+1
| | | | | | | | | | | | | | | | | | There are ways to close the window without hitting the code paths in the render loops that delete the animation controller. Probably if no frame was ever rendered. Change-Id: If3e9d2051525c4ff50eda19084c967578fe4f4b0 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Restore QQuickWindowPrivate::dragOverThreshold(d, axis, TouchPoint)Shawn Rutledge2019-09-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 2f85907193ad934d911fe97f7000ecb0662de8cb we added the first version of dragOverThreshold() for checking touchpoints. Then we turned it into a template function in 558bb0e3bbbd3eaca52b02946374f2106c3a3872 along with fixing a bug. This version is still in use in Qt Quick Controls 2: dragOverThreshold(qreal, Qt::Axis, const QTouchEvent::TouchPoint *, int) So now we restore it, keeping the bug fix, but not as a template function. Since ab5df626bef9365089ce716ce476bccae1d0a04b, Pointer Handlers do not need it for checking QQuickEventTouchPoints anymore. Change-Id: I97b84f533f52fa67ccd15ba6eb3ee64a4fe1b668 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Add dragThreshold property to Event HandlersShawn Rutledge2019-09-191-20/+0
|/ | | | | | | | | | | | | | | | | We need drag threshold to be adjustable on each handler instance instead of relying only on the system default drag threshold. For example in some use cases DragHandler needs to work with a threshold of 0 or 1 to start dragging as soon as the point is pressed or as soon as the point is moved, with no "jump", to enable fine adjustment of a value on some control such as a Slider. This involves moving the dragOverThreshold() functions that handlers are using from QQuickWindowPrivate to QQuickPointerHandlerPrivate, so that they can use the adjustable threshold value. Task-number: QTBUG-68075 Change-Id: Ie720cbbf9f30abb40d1731d92f8e7f1e6534eeb5 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Add the graphics api independent scenegraph portLaszlo Agocs2019-07-041-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Opt in via environment variables: QSG_RHI=1 -> enable using QRhi instead of GL QSG_RHI_BACKEND -> set to vulkan, metal, d3d11, gl to override the default (the default is d3d11 on Windows, metal on Mac, gl elsewhere) Or force a given rhi backend via the existing QQuickWindow::setSceneGraphBackend(). Otherwise the default behavior is the same as before, the rhi code path is never active by default. -no-opengl builds are supported in the sense that they work and default to the software backend. However, the rhi code path cannot currently be used in such builds, even though QRhi from qtbase is fully functional with Vulkan, D3D, or Metal even when qtbase was configured with -no-opengl. This cannot be utilized by Quick atm due to OpenGL usage being all over the place in the sources corresponding to the default backend, and those host the rhi code path as well. This will be cleaned up hopefully in Qt 6, with the removal all direct OpenGL usage. Other env.vars.: QSG_RHI_DEBUG_LAYER=1 -> enable D3D debug or Vulkan validation layer (assuming the system is set up for this) QSG_RHI_SHADEREFFECT_DEBUG=1 -> print stuff from ShaderEffect QSG_SAMPLES=1,2,4,... -> MSAA sample count (but QSurfaceFormat works too) QT_D3D_ADAPTER_INDEX=0,1,... -> D3D adapter index QT_VK_PHYSICAL_DEVICE_INDEX=0,1,... -> Vulkan physical device index QSG_RHI_UINT32_INDEX=1 -> always use uint index data (both merged/unmerged, convert when needed - with some rhi backends this is implicit) QSG_RENDER_LOOP -> to override the render loop as usual. The default with RHI is threaded for Metal, threaded for Vulkan on Windows, basic for Vulkan on Linux and Android (to be checked later), while the existing rules apply for OpenGL. Not supported when running with QRhi: - particles - compressed atlases (though this is transparent to the apps) - QSGRenderNode - QQuickRenderControl - QQuickFramebufferObject - certain QQuickWindow functionality that depends directly on OpenGL - anisotropic filtering for textures - native text may lack some gamma correction - QSGEngine applicability unclear - some QML profiler logs may be incorrect or irrelevant Change-Id: I7822e99ad79e342e4166275da6e9e66498d76521 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Add a feature for Drag&Drop support in Qt QuickUlf Hermann2019-05-231-2/+2
| | | | | | | | | | | Even if we have drag&drop in QtGui we don't necessarily want it in QtQuick. Also, since the QQuickDropArea needs QRegularExpression, quick-draganddrop needs to depend on regularexpression. Change-Id: I623e910178160ad3e3af3c01c96c30e88dc1b7ba Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Do not synthesize a double click event if the event point moved too farJan Arve Sæther2019-05-151-1/+2
| | | | | | | | We need to respect QPlatformTheme::TouchDoubleTapDistance Fixes: QTBUG-75770 Change-Id: I2adc7097bb29cb93beb2609a8a806a666856a0c8 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQWindow: cancel touch->mouse synthesis when touch is ungrabbedShawn Rutledge2018-10-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, each time a new touchpoint is pressed, we would purposely forget which touchpoint was acting as the mouse, as part of "starting over" with event delivery. Conceptually "starting over" ought to mean as freshly as possible; but in practice, if a user was using one finger to interact with some mouse-only Item, and then presses a second finger (whether intentionally or not), (s)he doesn't want the first interaction to immediately end. The multi-finger DragHandler must be able to take over the grab from the Item which already had the grab; but it uses a passive grab in the meantime to track the movement, and normally takes over the exclusive grab only when its preconditions are met: the point has to move past the drag threshold. So we can wait until then to reset the touchMouseId. The concrete use cases are: double-tapping a map is supposed to zoom in, even if there is a MouseArea on top. And, while dragging a Slider inside a Flickable, you should be able to start dragging the Flickable with a second finger. In the first case the issue was that the MouseArea could grab while handling the synth-event, thus setting touchMouseId; then touchMouseId was immediately reset again while handling the second touchpoint, so the second touchpoint would also be offered as a synth-mouse event to various items. But while fixing that, we have to avoid this issue in the Slider-in-Flickable case: when the first touch press is delivered, Flickable takes the exclusive grab temporarily; after moving the touchpoint, the Slider's DragHandler steals the exclusive grab. Then we try to deliver the second touchpoint press: at this time, we don't want touchMouseId to be set, because we want to be able to deliver synth-mouse events for the second point so that Flickable can grab that one. So it must be that when DragHandler steals the grab, we can reset touchMouseId, because the only reason it was set was that Flickable had the grab. This result is achieved by having QQuickItem::touchUngrabEvent() call a new QQuickWindowPrivate::cancelTouchMouseSynthesis() function. It was already a good idea to have such a function since we always reset touchMouseId and touchMouseDevice at the same time. Also modify the docs to remind users that when subclassing QQuickItem and overriding mouseUngrabEvent() or touchUngrabEvent() they should call the base class implementation, to avoid bypassing this new functionality. Fixes: QTBUG-70998 Change-Id: I02894971e9047d4fa7ac9d062d6714c9183a8058 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Make DragHandler a MultiPointHandlerShawn Rutledge2018-07-191-0/+1
| | | | | | | | | | That is, minimumPointCount can now be set to a value > 1 to require multiple fingers to do the dragging, or to track the displacement of multiple fingers to adjust some value (such as the tilt of a map). Task-number: QTBUG-68106 Change-Id: Ib35823e36deb81c8b277d3070fcc758c7c019564 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Replace MultiPtHndlr.pointDistanceThreshold with PointerHandler.marginShawn Rutledge2018-06-291-1/+1
| | | | | | | | | | | | | | | | It's not just useful for PinchHandler: TapHandler has a good use for it too. But unfortunately if the handler's parent Item has a custom mask, we don't have a way to augment the mask with a margin; so if margin is set, we assume the bounds are rectangular. QQuickMultiPointHandler::eligiblePoints() now calls wantsEventPoint() rather than bounds-checking the point directly: this adds flexibility, potentially allowing an override in subclasses, if we need it later. Task-number: QTBUG-68077 Change-Id: I65c95f00c532044a5862654e58c9c5f8c973df81 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Deliver QNativeGestureEvent via deliverSinglePointEventUntilAcceptedShawn Rutledge2018-06-211-3/+0
| | | | | | | | This just simplifies the code a little, and also enables event filtering during delivery to Items. Change-Id: I407dc9a19207f977b574f2a92f5da892e8752987 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Deliver QWheelEvent wrapped as QQuickPointerScrollEventShawn Rutledge2018-06-211-3/+1
| | | | | | | | | | | | and prepare to let Pointer Handlers see these events. There are several types of events which are delivered recursively by a less-complex algorithm: wheel, hover, native gesture etc. deliverSinglePointEventUntilAccepted() is intended for those. Task-number: QTBUG-68119 Change-Id: I68c2d77925daab6107354c1cc12bb525ded936b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* use the override keyword consistently and correctly (clang-tidy)Shawn Rutledge2018-02-271-1/+1
| | | | | Change-Id: If9e28d143f8cba3df3c757476b4f2265e2eb8b2a Reviewed-by: Johan Helsing <johan.helsing@qt.io>
* use nullptr consistently (clang-tidy)Shawn Rutledge2018-02-261-4/+4
| | | | | | | | | | | | | 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-01-091-1/+2
|\ | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/qml/memory/qv4mm.cpp src/qml/qml/qqmlbinding.cpp Change-Id: I98e51ef5af12691196da5772a07d3d53d213efcc
| * Merge remote-tracking branch 'origin/5.9' into 5.10Liang Qi2018-01-041-1/+2
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/qml/memory/qv4mm.cpp src/qml/memory/qv4mmdefs_p.h src/quick/items/qquickwindow.cpp src/quick/items/qquickwindow_p.h tests/auto/qml/debugger/qqmlprofilerservice/qqmlprofilerservice.pro tests/auto/qml/debugger/qqmlprofilerservice/tst_qqmlprofilerservice.cpp Change-Id: I7021fa1edf076627a67048f41f7b201220262b09
| | * grabMouse() and QQWPriv::removeGrabber(): be clear whether mouse or touchShawn Rutledge2017-12-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bug was that a MouseArea could be stuck in pressed state if a touch tap occurred simultaneously on a second MouseArea while the first was held pressed by the actual mouse. QQuickWindowPrivate::setMouseGrabber(QQuickItem *) had too little information to make the right choice in case the given item argument is null. It should not mean ungrab everything: in this use case, the mouse and the touchpoint can be pressing two different MouseAreas, and releasing either one should ungrab only the MouseArea that is being released. However the only place it was called with nullptr was in removeGrabber(), and in that context we are given all the information: which item to ungrab and whether we want to ungrab mouse, touch or both. It's better to have a little code duplication between QQuickItem::grabMouse() and QQuickWindowPrivate::removeGrabber() than to lose this information about which device(s) and Item to ungrab. Task-number: QTBUG-64249 Change-Id: I0710534a05f3ceeb66105a03ab0f32a61df8a522 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | | Merge remote-tracking branch 'origin/5.10' into devLiang Qi2017-12-201-0/+1
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+1
| |\| | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/quick/items/qquickwindow.cpp src/quick/items/qquickwindow_p.h tests/auto/quick/quick.pro Change-Id: Ia12f20e95fb151bbbc75dbf187364a924cd0bc7a
| | * Never create pointer events from mouseGrabberItem()Jan Arve Saether2017-11-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, this was not a problem, but it is problematic during QQuickWindow destruction: The list of pointer event instances are destroyed, but later the grabber is removed (through call to removeGrabber()). This queries the mouseGrabberItem(), which would create a new pointer event instance. It also has the benefit that d->pointerEventInstances are now only populated due to actual incoming events. Task-number: QTBUG-61434 Change-Id: I4e7b6f5643f3b971138a1f7c7237ee734d29783c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | | Merge remote-tracking branch 'origin/5.10' into devLiang Qi2017-11-061-1/+2
|\| | | | | | | | | | | Change-Id: I1ed923d72566af663555898c3ec708191eef8ae9
| * | Fix a bug with TapHandler+DragHandler on top of FlickableJan Arve Sæther2017-10-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If an item that had a TapHandler and a DragHandler was placed inside a Flickable it would call sendFilteredPointerEvent() for each of the handlers, even if they were siblings. This is not ideal, and because of a mechanism in flickable it even caused the DragHandler to not drag the item as expected. This is because of a mechanism in Flickable where the value returned is actually derived from the previous call to filterMouseEvent() (stored in member variable stealGrab). Below are the relevant steps it went through when the mouse drag exceeded the drag threshold (mouse pointer started on the item): Precondition: QQuickFlickablePrivate::stealMouse == false 1. Mouse Drag (which exceeded drag threshold) 2. sendFilteredPointerEvent(tapHandler->parentItem()) returns false. (but since it moved beyond threshold, it would set stealGrab-> true). 3. tapHandler->handlePointerEvent() declined and ungrabbed (due to DragThreshold gesture policy). 4. sendFilteredPointerEvent(dragHandler->parentItem()) returns true (because the previous call to sendFilteredPointerEvent() set stealGrab to true). As a consequence of (4), dragHandler->handlePointerEvent() was not called, and the flickable would start to flick instead of the item starting to drag. Change-Id: Ia99eae91cad0903ebbaedaaafcdf92a25705a922 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
| * | PinchHandler: add native pinch gesture supportShawn Rutledge2017-09-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | macOS generates QNativeGestureEvents for 2-finger trackpad zoom and rotation gestures. Now PinchHandler will react to them in the same way that PinchArea does. Change-Id: I4c7dab1d3561d20897e3671f4eb68d01ea06b9bd Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | | Replace Q_DECL_OVERRIDE with overrideKevin Funk2017-09-251-1/+1
|/ / | | | | | | | | Change-Id: I176f91a8c51e81a2df3fe91733118261491223ee Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | don't re-deliver events to an item which already filteredShawn Rutledge2017-09-111-1/+2
| | | | | | | | | | | | | | | | | | That is, if the filtering parent intercepts an event (returns true from childMouseEventFilter), it does not also need direct delivery of the same event. Change-Id: I24003f72875b309fa10b2d316916c5f86702cb57 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | refactor sendFilteredMouseEvent to match sendFilteredPointerEventShawn Rutledge2017-09-111-1/+1
| | | | | | | | | | | | | | and eliminate more temporary QSets. Change-Id: I03b556295b75f919c2c22f8f8884b1d54d6654c0 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | sendFilteredPointerEvent: go back to parent traversalShawn Rutledge2017-09-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The filteringParentItems vector-of-pairs is getting more and more questionable: it needs to have more pairs than we thought, then we need to remove them to prevent multiple-filtering, and then we also need to keep track of which ones we removed plus which ones are actually filtering, in order to avoid direct delivery of pointer events to the same Item after it already filtered from its children. The overhead doesn't seem worthwhile anymore. So this conceptually reverts 9b5fc80af28580e9672792dd511d876a93947882 but with some improvements. Also, do not deliver events to child-filtering items which have already filtered. Change-Id: I9d4f977dba695de7eb78ab536e0e6e8fd6a253a7 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | rename QQuickEventPoint pos properties to positionShawn Rutledge2017-09-051-1/+1
| | | | | | | | | | | | | | | | For consistency we always spell it out, although it does make some of these properties inconveniently verbose. Change-Id: I64a08c3aa261c0ab89e09472dd47510abafbf7ca Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Restore filtering behaviorShawn Rutledge2017-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We cannot cull pairs from filteringParentItems ahead of time on the basis of not visiting the same parent twice, because we don't know which child will get the press event. Skipping parents which have already seen the event once MUST be done during event delivery, as it was done before 9b5fc80af28580e9672792dd511d876a93947882 But another behavior difference is that the same parent can filter twice, if it's filtering the same event on behalf of a different item. For example: ListView delegate: Rectangle MouseArea Text If you click on the text, the MouseArea can filter for the Text, then ListView filters for the Text. Nobody accepts. So we try to deliver to the MouseArea; and then ListView filters again, this time for the MouseArea. So we need to go back to interleaving regular delivery and parent-filtering to get back to the behavior we had in 5.9. It's not the same if we try to do all the parent-filtering first, and then all the regular delivery afterwards. Revises and reverts parts of 1b0c9b46ce13b0f9c533f18fb420ff10ad56e4f6 Done-with: Jan Arve Sæther Task-number: QTBUG-62412 Task-number: QTBUG-62549 Task-number: QTBUG-62628 Task-number: QTBUG-62631 Change-Id: Id0bf64cb54668cc0eecfba01746a00ed7ea0359f Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Add a way to set the default render type of text-like elementsGiuseppe D'Angelo2017-08-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | f3446071da8357620d0c8593a04e3b4fbba88f21 introduced a build-time way to select the default render type of text-like elements. This patch adds also a way to select it at runtime, via a setter on QQuickWindow. (QQuickWindow has been chosen as convenience, rather than adding another namespace/class to just have this setter.) Given that QT_QUICK_DEFAULT_TEXT_RENDER_TYPE was never documented, I've taken the liberty of changing the accepted values for it (to match the new enumerator names in QQuickWindow, rather than the ones in QQuickText/QQuickTextEdit/etc.). [ChangeLog][QtQuick][QQuickWindow] It is now possible to set the default render type of text-like elements globally via the QQuickWindow::setTextRenderType() function. If you were using the (undocumented) QT_QUICK_DEFAULT_TEXT_RENDER_TYPE macro when building Qt Quick for the same purpose, note that the macro value needs now to be set to the "NativeTextRendering" value, instead of "NativeRendering". Change-Id: Id4b2dc3ec823971486e445ca4173b8be848fb4e3 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
* | Fix some bugs related to child mouse filteringwip/pointerhandlerJan Arve Saether2017-08-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Only abort event delivery early if event that got filtered was accepted (previously we aborted as soon as the event got filtered, even if the event was filtered, but explicitly *not* accepted) - If the event that got filtered was *not* accepted, we do not abort event delivery, but we need to remove the item from the list of target items that we will deliver to later - If childMouseEventFilter returns true it should not automatically mean that the event was accepted. Change-Id: I2f2415379061131af1d5102e03d01f010e1a8168 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* | Merge remote-tracking branch 'origin/dev' into wip/pointerhandlerJan Arve Saether2017-07-111-0/+4
|\| | | | | | | | | | | | | | | | | | | | | Conflicts: examples/quick/shared/LauncherList.qml src/quick/items/qquickevents.cpp src/quick/items/qquickevents_p_p.h src/quick/items/qquickwindow.cpp tests/auto/quick/touchmouse/tst_touchmouse.cpp Change-Id: Id692d291455093fc72db61f1b854f3fc9190267b
| * Move pointerEvent instance to QQuickWindowJan Arve Saether2017-05-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | With two or more windows, if events are being delivered to each, the grabbers can be different in each. We need unique instances of the QQuickPointerEvent objects for each window to avoid losing the grab state in the parent window while delivering a synthesized event to a subwindow, for example. Change-Id: I51da1212d573853969e32ad78f5b219d979a8a5c Task-number: QTBUG-57253 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Fix some problems with MouseDblClick handlingJan Arve Saether2017-05-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The sequence of events delivered from a double click is: [Press,Release,Press,DblClick,Release] The problem was that a DblClick was delivered just like a press event, so it would clear the passive grabber that was established because of the former Press event. When the Release event then got processed, there was therefore a risk that the Release event was not delivered to the passive grabber. The fix is to not deliver DblClick events at all to handlers, and to not deliver DblClick to items if the former Press event was accepted by a handler. Change-Id: I49c0e32ef4e33f7b6014d35dc065da2527b94779 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Start over with event delivery when touchpoint releases occurShawn Rutledge2017-05-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new rule is that when the number of touchpoints changes, we start over with event delivery as if the touch had just begun, to give more opportunities to hand off processing from one item or handler to another. And MultiPointTouchArea can now handle the handoff: for example in tests/manual/pointer/pinchDragFlingMPTA.qml when the user is pressing three fingers, the PinchHandler is active; when the user then lifts one finger, the MPTA can resume handling the two remaining touchpoints as if they were just pressed. The change in QQuickMultiPointerHandler::wantsPointerEvent is both a behavior change and an optimization: released points aren't eligible; but if some points are released, then pressed, updated and stationary points are all eligible. And, figure this out without looping over the points twice. Change-Id: I26b7593de8e72b471adfec4a4482dd87a8288442 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Add QQuickItem acceptTouchEvents/setAcceptTouchEvents; require for touchShawn Rutledge2017-04-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | QQuickEventPoint API changes after API reviewJan Arve Saether2017-02-221-0/+8
| | | | | | | | | | | | | | | | | | | | * localize -> localizePosition * remove isValid and invalidate * remove isDraggedOverThreshold * remove Q_INVOKABLEs Change-Id: I21f788beb1e86275a9b7a1f1014998b2569001d0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | remove unused return values in QQuickWindowPrivate delivery functionsShawn Rutledge2017-02-161-2/+2
| | | | | | | | | | Change-Id: Ie75bd04f1ec12805b83f218d86f7b235ba44e0fc Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | QQuickWindow: remove sendFilteredTouchEventShawn Rutledge2017-02-161-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The functionality is now completely assimilated into sendFilteredPointerEvent. Flickable can now steal the touch grab from a TapHandler child, for example: the TapHandler grabbed the eventpoint, whereas QQuickFlickable::childMouseEventFilter() was given a synthetic mouse event derived from the touchpoint which the eventpoint represented, and we fully follow through the consequences of that. If an Item filters a press event, avoid doing normal delivery to that same Item again. Change-Id: Icd9c88ab752f2b728f7d612504013c6dc72ff9fe Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | build a vector of child-filtering parents before delivery of pointer eventShawn Rutledge2017-01-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-14 01:05:55 +0000