aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/handlers/qquickdraghandler.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add snapMode to DragHandlerJan Arve Sæther2019-05-161-2/+35
| | | | | | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'origin/5.13' into devQt Forward Merge Bot2019-04-101-4/+3
|\ | | | | | | | | | | | | | | Conflicts: src/qml/qml/qqmlmetatype.cpp src/qml/types/qqmlmodelsmodule.cpp Change-Id: Idc63689ba98d83a455283674f4b5cf3014473605
| * If DragHandler is dragged within its margin, don't jumpShawn Rutledge2019-04-051-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Not being pressed inside the target is a necessary but not sufficient reason to reset m_pressTargetPos to the center of the target. The intention was rather to make the target jump into position when the parent was a different item: e.g. if a Slider has a DragHandler whose target is the slider's knob, you can start dragging anywhere on the whole Slider but you want the knob to jump to the cursor position when the drag begins. While we're at it, both branches of the if in onGrabChanged() are checking that target() isn't null, so we can move that check out. Fixes: QTBUG-74966 Change-Id: I05be11d27422b070d941b9e43d4e1157e071c3a5 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Refactor QQuickMultiPointHandler into public and private classesShawn Rutledge2019-04-021-4/+4
|/ | | | | Change-Id: Iec19664862bfbbf9a6c582dac441dda26eec57db Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Doc: Fix link issuesNico Vertriest2019-01-031-1/+1
| | | | | Change-Id: I738b9da5335afb048d2eda2edf2be5095a91d7e5 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Doc: Show that DragHandler is now a multi-point handlerShawn Rutledge2018-09-111-1/+1
| | | | | | | | | Inheritance changed, and that means it has a centroid property. Amends ca7cdd71ee33f0d77eb6bf1367d2532e26155cb2 Task-number: QTBUG-68106 Change-Id: Ie68eb1376868b143dd56564a3abc896dd7e745c6 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Rename QQEventPoint::GrabState to GrabTransitionShawn Rutledge2018-08-311-3/+3
| | | | | | | | | | | | | | | | | | | 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>
* Doc: clarify the type and meaning of QQuickMultiPointHandler::centroidShawn Rutledge2018-08-221-1/+3
| | | | | | | | | | | | Amends 52d35526f256bf4c8155f5e660a214ab8a2efbdf : it's now a QQuickHandlerPoint rather than QPointF, and is inherited from MultiPointHandler to DragHandler and PinchHandler. So the docs can be inherited too, but in PinchHandler it seems more appropriate to keep the overridden docs which explain that transformation around the centroid depends on pinchOrigin. Task-number: QTBUG-70074 Change-Id: I8875b38439fe80c311a685ab9e3dedc9357415e8 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Fix PointerHandler constructors and destructorsShawn Rutledge2018-07-271-5/+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>
* Rearrange docs: Pointer Handlers -> Input HandlersShawn Rutledge2018-07-261-2/+2
| | | | | | | | | | | | | | | At QtCS 2018 we decided to rename Pointer Handlers to Input Handlers and include the Keys attached property as part of this set (since we plan to have attached-property pointer handlers too, eventually). It's no longer a module, it's included in Qt Quick 2.12. We need to start promoting Input Handlers and reducing the visibility of legacy stuff like MouseArea and MultiPointTouchArea (in the hope of being able to deprecate them eventually). Task-number: QTBUG-66651 Change-Id: I801351ac2531191cbb1faac9318441c67a109af6 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* Make DragHandler a MultiPointHandlerShawn Rutledge2018-07-191-65/+125
| | | | | | | | | | 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>
* Rename Pointer Handlers to Input Handlers (as a concept)Shawn Rutledge2018-07-121-1/+1
| | | | | | | | | | | | | | | | This is a documentation change to alleviate some confusion that we've seen during the Tech Preview period. It doesn't make sense to actually rename the base class though, because it is intended to handle QQuickPointerEvents, not QEvents. The reason for that is that refactoring the QEvent hierarchy has to wait until Qt 6. So maybe in Qt 6 we can remove QQuickPointerEvent and have a QQuickInputHandler base class which handles QInputEvents; but for now, this conceptual renaming seems about as far as we can go. Task-number: QTBUG-66651 Change-Id: I84a41dc282c480d08f4d4a0d9a857e37e074aa7a Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* Put QQuickDragAxis into a separate fileJan Arve Sæther2018-06-251-33/+0
| | | | | | | Needed because it will be used by other handlers Change-Id: I2fb6d83e29410a3bdce1e037d3ef0670a282ce14 Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
* Don't crash if DragHandler have target: nullJan Arve Sæther2018-03-021-6/+8
| | | | | Change-Id: Ie5c5367439f8773eb523ef5d639a018a2fd59c65 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* doc: Fix several Can't link to errorsMartin Smith2018-02-281-20/+30
| | | | | | | | This update corrects several "Can't link to..." errors and splits a \qmlpropertygroup into two separate \qmlpropertygroups. Change-Id: Ic9b89a11eef64069154a932dd9dedf18279506a2 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* doc: Correct mostly linking errorsMartin Smith2018-02-231-4/+5
| | | | | | | | | This update corrects many qdoc warnings, mostly of the "Can't link to..." variety, but there were also a few qdoc comments added. As of this update, the qdoc warning count is 46 in QtDeclarative. Change-Id: Icf2d34c7ce7010ebfd9b474feacfe8af42f3fd5f Reviewed-by: Martin Smith <martin.smith@qt.io>
* Fix draghandler to respect axis constraintsJan Arve Sæther2018-02-211-34/+54
| | | | | | | | | | | | | | | | | | | | | | | ..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>
* Fix a bug with calculation of translation in DragHandlerJan Arve Sæther2017-11-241-3/+4
| | | | | | | | | | | | | | | | The problem was that the start position of the target item (m_targetStartPos) was not always updated. In combination with several handlers (this bug was observed with PinchHandler and DragHandler as siblings) it is quite likely that the DragHandler will get a press, but not activate (because the PinchHandler might activate instead). It would therefore not deactivate (so it would not reset m_targetStartPos), and as a consequence the m_targetStartPos was not updated to its correct value the next time we initiated a drag because m_targetStartPos wasn't null. Change-Id: Icf3089fc685cfbcbcfba638966a2e8ad1c8c089f Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* improve documentation of DragHandlerShawn Rutledge2017-09-291-2/+38
| | | | | Change-Id: Ifde67ba567b447da948b79d32676458fd0628ec5 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* change the type of DragHandler::translation to QVector2D; document itShawn Rutledge2017-09-291-2/+9
| | | | | | | | 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 QQuickEventPoint pos properties to positionShawn Rutledge2017-09-051-3/+3
| | | | | | | | 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>
* Rename single and multi pointer handler classnamesJan Arve Sæther2017-09-031-3/+3
| | | | | | | | | Renames: QQuickPointerSingleHandler -> QQuickSinglePointHandler QQuickMultiPointerHandler -> QQuickMultiPointHandler Change-Id: I10c54944f85ca7cac374ebc6241d61793e2d38bf Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Move properties into grouped "point" propertyJan Arve Saether2017-05-231-1/+1
| | | | | Change-Id: I80000110a2e0ca69210322a0fcc587d86158358e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add and use QQuickPointerSingleHandler::moveTarget()Shawn Rutledge2017-04-281-1/+1
| | | | | | | | | | | | Until now, DragHandler::pos() was not staying constant during a drag, because we update m_pos from the EventPoint, then move the Item. scenePos() also returns mapToScene(m_pos). If the Item is being dragged to follow the finger or the mouse cursor exactly, unconstrained, then pos() should always be the same as the parent-relative position where the press occurred. Change-Id: Ia02738c0cf458e039cf90371f9c8a7becb75a035 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* DragHandler: allow parent to be different from targetShawn Rutledge2017-04-271-6/+31
| | | | | | | | | | | | | | | 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/+6
| | | | | | | | | 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>
* DragHandler: don't steal exclusive grabShawn Rutledge2017-03-301-2/+3
| | | | | Change-Id: I643d0e93e180bba5d9fea4543b93cbb66668c94d Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* DragHandler: keep the grab (prevent stealing) when draggingShawn Rutledge2017-02-171-0/+8
| | | | | | | | | | | | | Whenever the DragHandler gets an exclusive grab, it needs to prevent a parent Flickable (for example) from taking over that grab. Since it waits until the drag threshold is exceeded in an allowed dragging direction, this does not prevent the Flickable from being draggable in the other direction. We restore the state of keepTouchGrab and keepMouseGrab when ungrabbing. Change-Id: Id9d456c99322e0cb6996d1f690b38fcd6becc6f9 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* start making explicit exclusive or passive grabsShawn Rutledge2017-02-101-2/+3
| | | | | Change-Id: I4a6e3c72d69e893fec2e39f4faab24af6d00c7e0 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QQPSingleHandler: copy some values from QQuickEventPoint to propertiesShawn Rutledge2017-01-031-1/+1
| | | | | | | | | We can't copy the eventpoint and we can't continue to refer to it after delivery, either. So we can't have an event property. Some QML use cases depend on being able to access last-known values between events. Change-Id: Ice8a1763015f2554275d0cb76824fd0366eaef56 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Add a DragHandler::translation propertyJan Arve Saether2016-12-291-0/+10
| | | | | | | | | | | | | | 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-10/+1
| | | | | | | | | | | | | | | | | 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>
* Don't assume that target is the parent itemJan Arve Saether2016-12-291-3/+0
| | | | | | | | | | | To summarize: A pointer handler always gets its pointer events from its parent item. It applies its effect (drag, pinch, ...) on the item referenced to by the target property. By default, target refers to the parent, but that is not always the case. In addition to this we also have to handle the case when the target is null Change-Id: If62108abf0aeb713906bf88472ad9a32a74efff6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fixed bug in DragHandler when dragging in scaled coordinate systemJan Arve Saether2016-12-271-4/+7
| | | | | | | | | | | | | Calculate the new position in the target items' parent coordinate system in order to not be affected by any transformations applied on the target item. And after all, the item's position is specified in parent coordinates. Also check target() and target()->parentItem() rather than assuming that they are non-null. Change-Id: Ib00c72cce7b324b508884287e4070bedaf02b95e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* DragHandler: override wantsEventPoint to retain interest out of boundsShawn Rutledge2016-12-091-0/+7
| | | | | | | | | | 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>
* DragHandler: grab when dragging over the thresholdShawn Rutledge2016-10-171-0/+1
| | | | | Change-Id: I529987797a3fdce967cdac21f29d3a067e0cbd4b Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
* Introduce DragHandlerShawn Rutledge2016-08-261-0/+160
A handler for dragging Items around by touch or mouse. Change-Id: Id83fea568095eb6374f3f1abc6f550d81f3731df Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-24 08:57:31 +0000