| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
..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>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
Renames:
QQuickPointerSingleHandler -> QQuickSinglePointHandler
QQuickMultiPointerHandler -> QQuickMultiPointHandler
Change-Id: I10c54944f85ca7cac374ebc6241d61793e2d38bf
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
Change-Id: I17b3865d70bdc07912d7454b459dea40b9c98df0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
| |
Change-Id: I4a6e3c72d69e893fec2e39f4faab24af6d00c7e0
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
Change-Id: I63464ccafc56e2e398448ed90a9cb852304e90eb
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
A handler for dragging Items around by touch or mouse.
Change-Id: Id83fea568095eb6374f3f1abc6f550d81f3731df
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
|
