| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: Id72fbe10c16de61bd847773d0055d83cfe03f63c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
This property was added in Qt 5.14.
Change-Id: I48ebc614490e67440419965983126740c4443d0e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: Ica67409f3138828d8a33fef2d67ad799a5a063f5
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Needed because it will be used by other handlers
Change-Id: I2fb6d83e29410a3bdce1e037d3ef0670a282ce14
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|