This is a workaround for platforms (such as Wayland and macOS) that are sometimes failing to distinguish mouse and touchpad. It's better for illustrative purposes anyway, since a laptop user may really be using a touchpad rather than a mouse, and we hope to eventually distinguish them on as many platforms as possible. Task-number: QTBUG-63363 Task-number: QTBUG-112432 Pick-to: 6.5 6.6 6.7 Change-Id: Ic7a374f1257d4aa57f29385b44da85ccaf4f5ec6 Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io> Reviewed-by: Doris Verria <doris.verria@qt.io>
PointerDevice.GenericPointer was the enum value in Qt5, but in Qt6 this changed to PointerDevice.Generic Pick-to: 6.2 6.5 Change-Id: Ic5e4a5fe5fd91f7478d00e0d2c643b99eaa7ab14 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Many of the inherited docs were inappropriate or insufficiently specific to PointHandler. Now we have more snippets with more ideas for how it can be used. As a drive-by, fix a typo in the docs for PointerDeviceHandler::acceptedPointerTypes and add a link to the new PointerDevice page added in e283c05af745210d4a1f6c0aa9c33bf4da23a1e0 Pick-to: 6.2 6.4 6.5 6.5.0 Fixes: QTBUG-74020 Fixes: QTBUG-106878 Change-Id: I028e1577ac5d4ef0b927c94259d6ab25b6028885 Reviewed-by: Doris Verria <doris.verria@qt.io>
TapHandler must decide on press whether it's interested in tracking a particular point further, to see if a qualifying tap occurs, and should only care about those points it decided to track. But if it did not decide to track it, wantsEventPoint() should never care about the point movement after press; nor about hovering points either. The line in QQuickPointerDeviceHandler::wantsPointerEvent() checking pointingDevice()->pointerType() != Finger was also making touchpad behavior inconsistent with mouse behavior, which is why this bug appeared on macOS but not on Linux: QQuickPointerDeviceHandler needs to care about the incoming event's buttons on all devices except touchscreens. It's probably been causing other symptoms on touchpads since a97760a336c597327cb82eebc9f45c793aec32c9. For the test, a05cbaaae505dba2546c593e22fe2f9047c0de4b restored the cumulative native gesture scaling as it should be: so if we try to scale by 1.1 twice in a row, the result is it's scaled by 1.21. Pick-to: 6.2 6.4 6.5 Fixes: QTBUG-108896 Change-Id: I3da8878648b89cce5d1a48fa02dffaefead2ac90 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Doris Verria <doris.verria@qt.io>
Now uses the proper enums and exposes all necessary classes to QML. Change-Id: I04cc390469c5811ad4683454b460829fa1e86582 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Pick-to: 6.4 Task-number: QTBUG-67283 Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Including moc files directly into their classes' TU tends to improve codegen and enables extended compiler warnings, e.g. about unused private functions or fields. Pick-to: 6.3 6.2 5.15 Task-number: QTBUG-102948 Change-Id: I695daa12613de3bada67eb69a26a8dce07c4b85e Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
When the gesture begins, we begin multiplying the target item's scale by 1.0 at first; it doesn't make sense to start immediately with the accumulated scale remembered from previous pinch gestures, because the target item remembers its own scale. When QQuickPinchHandler::wantsPointerEvent() returns false because some irrelevant gesture was received (for example a PanNativeGesture), that's not a good reason to deactivate. Deactivating and re-activating with each ZoomNativeGesture event results in extreme behavior, because PinchHandler depends on the BeginNativeGesture and EndNativeGesture events to reset internal state. Likewise, the fact that the button state is NoButton is not a good reason for wantsPointerEvent() to return false. Added an autotest: the first of its kind that actually simulates the native gesture events. Fixes: QTBUG-92064 Pick-to: 5.15 6.0 6.1 Change-Id: I3a9b92d70f99497ee58ad8557d90d521fbe16d41 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
- Remove links to modules and examples that are not part of Qt 6. - Remove links to entities marked as \internal - Add missing enum value and QML property docs where it's trivial to do so. Task-number: QTBUG-88156 Change-Id: I10a1c7bcc5fe0e2354ea69eaf24930362edb7415 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
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>