aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/handlers/qquickdraghandler.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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>