aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/handlers/qquickdraghandler_p.h
Commit message (Collapse)AuthorAgeFilesLines
* Remove QQuickPointerEvent etc.; deliver QPointerEvents directlyShawn Rutledge2020-09-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Add major version to all Q_REVISIONsUlf Hermann2020-02-191-3/+3
| | | | | Change-Id: Id72fbe10c16de61bd847773d0055d83cfe03f63c Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Specify parameters of type registration in class declarationsUlf Hermann2019-09-261-0/+2
| | | | | | | | | | | | | | | | | | | | | Using this technique we can automatically register all necessary revisions and minor versions of a type, using the metaobject system. This greatly reduces the potential for mistakes and resulting incompatibilities between versions of imports. We assume that for each type we need to register all revisions of its super types and its attached type, and that the revisions match. That is, if you import version X of type A, you will also get version X of its attached type and of any super types. As we previously didn't take these dependencies into account when manually registering the types, a number of extra revisions are now registered for some types. Potentially, we can now generate the qmltypes files at compile time, using moc. Change-Id: I7abb8a5c39f5e63ad1a0cb41a783f2c91909491b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* QQuickDragHandler: Add revision to snapModeUlf Hermann2019-08-281-2/+2
| | | | | | | This property was added in Qt 5.14. Change-Id: I48ebc614490e67440419965983126740c4443d0e Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Add snapMode to DragHandlerJan Arve Sæther2019-05-161-0/+13
| | | | | | | | | | | | | | | | | This changes snap behavior slightly. Basically, it does not snap anymore if the target() item is an ancestor of the parentItem(). In addition, we add a property that enables users to change the behavior. (SnapIfPressedOutsideTarget has the old behavior) [ChangeLog][QtQuick][Event Handlers] Added DragHandler.snapMode which can be used to configure under which conditions the dragged item is snapped to be below the cursor. The default mode is SnapAuto. The old behavior can be obtained through the SnapIfPressedOutsideTarget mode. Fixes: QTBUG-75661 Change-Id: Ibc00e8fbe31b779f8e817af1505e76425467d27a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Export all private Input Handlers and related classesShawn Rutledge2019-03-181-1/+1
| | | | | | | | | | This was the intention already in 5.12, but we left it with Q_AUTOTEST_EXPORT until now. Users should be able to begin experiments with subclassing handlers, since that is intended to be officially supported in 5.14 with public headers. Change-Id: I89471b3ef748936059ed4444eac5348d26a3344b Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Remove dubious API features and clutter from Pointer Handler headersShawn Rutledge2018-08-311-1/+0
| | | | | Change-Id: Ica67409f3138828d8a33fef2d67ad799a5a063f5 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Remove Q_INVOKABLE from DragHandler.enforceConstraints()Shawn Rutledge2018-08-311-1/+1
| | | | | | | We don't have any current use case for calling this method from QML. Change-Id: I72df37645c93475684fe8d0bc2e5a0582dcecad4 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Rename QQEventPoint::GrabState to GrabTransitionShawn Rutledge2018-08-311-1/+1
| | | | | | | | | | | | | | | | | | | This enum represents a transient state transition, and only sometimes corresponds to the current grab state of an event point. For example after exclusive grab has been canceled, the current state is that there is no exclusive grab: it doesn't make sense to remember that the way it got there was by cancellation. There was an idea to add a grabState property, but not all values would be eligible. An EventPoint can be exclusively grabbed by one item or handler at a time, and by multiple passive grabbers at the same time, so even a Q_FLAG would not fully express all possible states. Besides, there is already an exclusiveGrabber property, and we could add a passiveGrabbers list property if we had a real need. So adding a grabState property seems unlikely, and therefore is not a good enough reason to keep this enum named as GrabState. Change-Id: Ie37742b4bd431a7e51910d79a7223fba9a6bd848 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Fix PointerHandler constructors and destructorsShawn Rutledge2018-07-271-2/+1
| | | | | | | | | | | | | - Constructors should take QQuickItem* not QObject* to be symmetric with the parentItem() accessor (and other code) which assumes its type - Use header initialization everywhere possible - Reorder variables to minimize padding (somewhat) - Remove empty destructor bodies (the compiler can write them) - Remove override and virtual from destructors in accordance with https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override Change-Id: I682a53a803d65e29136bfaec3a5b534e975ecf30 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Make DragHandler a MultiPointHandlerShawn Rutledge2018-07-191-8/+6
| | | | | | | | | | 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>
* Put QQuickDragAxis into a separate fileJan Arve Sæther2018-06-251-30/+1
| | | | | | | Needed because it will be used by other handlers Change-Id: I2fb6d83e29410a3bdce1e037d3ef0670a282ce14 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* use nullptr consistently (clang-tidy)Shawn Rutledge2018-02-261-1/+1
| | | | | | | | | | | | | 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>
* Fix draghandler to respect axis constraintsJan Arve Sæther2018-02-211-2/+8
| | | | | | | | | | | | | | | | | | | | | | | ..while its (ancestor) coordinate system has changed during the drag. For example, ensure that a DragHandler-based Slider keeps its knob centered. If the Slider is used on a Flickable which you are flicking with a second finger, then the coordinate system is changing underneath the Slider. The problem was that DragHandler stored the initial drag position of the target when the target item was pressed, and used that throughout the whole drag operation. Unfortunately if the target item was inside a Flickable that got flicked during a drag operation, that initial position was not updated (and thus, incorrect). Instead of storing the initial target position in scene coordinates, we now store the position that got pressed in local target coordinates, and ensure that in any further updates the touchpoint have the same local position (by moving the target). Task-number: QTBUG-64852 Change-Id: I25012d34d88f45c7eb9c711db0037d530cf10854 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* change the type of DragHandler::translation to QVector2D; document itShawn Rutledge2017-09-291-4/+4
| | | | | | | | For consistency we use QVector2D to represent relative movements in all Pointer Handlers. Change-Id: I23dc20c360b482a995d232e8a6d7e87d9bd8f600 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Rename single and multi pointer handler classnamesJan Arve Sæther2017-09-031-2/+2
| | | | | | | | | Renames: QQuickPointerSingleHandler -> QQuickSinglePointHandler QQuickMultiPointerHandler -> QQuickMultiPointHandler Change-Id: I10c54944f85ca7cac374ebc6241d61793e2d38bf Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* DragHandler: allow parent to be different from targetShawn Rutledge2017-04-271-1/+3
| | | | | | | | | | | | | | | The most obvious way to implement a Slider is to allow dragging the knob - as on a real-world physical sliding potentiometer. But to make it easier on a touchscreen, it should be possible to touch anywhere along the slider's travel, as on a QtQuick.Controls 2 Slider. For that purpose, we need to respond to events within the bounds of one Item while actually dragging a different Item (the knob). It's similar to the way that PinchHandler can handle pinch gestures within one Item while transforming another (which may be too small to get both fingers inside). Change-Id: Iac9a5f11a7a45e22d93fe52bf62d157c48d72d3d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* DragHandler: onGrabChanged, enforceConstraintsShawn Rutledge2017-04-241-0/+1
| | | | | | | | | If the grab is stolen by a parent such as a Flickable, ensure that the DragHandler doesn't keep dragging. This helps to prevent dragging sliders out of their "groove" constraints. Change-Id: Id24f53e137ed186b1c02ab9c73a69a59022e80b0 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Make all handler constructors explicitJan Arve Saether2017-02-211-1/+1
| | | | | Change-Id: I17b3865d70bdc07912d7454b459dea40b9c98df0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* start making explicit exclusive or passive grabsShawn Rutledge2017-02-101-1/+1
| | | | | Change-Id: I4a6e3c72d69e893fec2e39f4faab24af6d00c7e0 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Add a DragHandler::translation propertyJan Arve Saether2016-12-291-0/+6
| | | | | | | | | | | | | | This allows the application developer to get the translation of the dragged pointer, and apply it in a custom way. This should usually be combined with setting target to null. This will for instance be needed when we want to drag QtLocations map, where a map is dragged by specifying the geo location of the center of the map. The map2.qml example demonstrates this. Change-Id: I652d9fc92fa9b6dfd3796c7147832f25af0cc5bc Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* DragHandler active property replaces dragging; same as grabbingShawn Rutledge2016-12-291-5/+0
| | | | | | | | | | | | | | | | | If a QQuickPointerSingleHandler grabs a point, it's definitely in the active state: doing something with the point. (The converse is not always true though: e.g. TapHandler can sometimes detect a tap without ever grabbing.) In DragHandler, the "dragging" property means the same as "active": we always grab when dragging, to be sure to get the updates. So the "dragging" property is removed because it's redundant. In QQuickPointerHandler we don't say that "wanting" an event is the same as being active, because 1) it won't necessarily grab right away and 2) every handler which was active should "want" the release event, yet it needs to setActive(false) as soon as it's done processing it. Change-Id: Ie010db54714a7914109da6469e79865f9a0a18e4 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* DragHandler: override wantsEventPoint to retain interest out of boundsShawn Rutledge2016-12-091-0/+3
| | | | | | | | | | In any use case where the movement is constrained, as in a slider or scrollbar, it's possible to keep dragging even when the eventpoint is out of bounds. QQuickPointerSingleHandler::wantsEventPoint() returns false when the point is out of bounds, so we have to override it. Change-Id: Id80f614d6c38f28e6520ee8eacf7649f7317a5ef Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* pointerhandlers: replace Q_DECL_OVERRIDE with overrideShawn Rutledge2016-12-091-1/+1
| | | | | Change-Id: I63464ccafc56e2e398448ed90a9cb852304e90eb Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Introduce DragHandlerShawn Rutledge2016-08-261-0/+130
A handler for dragging Items around by touch or mouse. Change-Id: Id83fea568095eb6374f3f1abc6f550d81f3731df Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>