| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far it was checking parentContains() on press, release, or when
the gesturePolicy is WithinBounds, but not for each movement when the
policy is DragThreshold (the default). This might explain most of the
remaining warning noise: "pointId is missing from current event, but was
neither canceled nor released" because it was possible for TapHandler
to remember wanting a point that it should not have wanted, but without
taking any kind of grab, and then complaining when that point was no
longer present. Since it did not grab, it did not get the release,
unless the release was part of an event containing a point that it
DID grab.
Fixes: QTBUG-71887
Change-Id: I26ce62279574cf6b0150f24e486f224a604ac6b1
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
| |
Fixes: QTBUG-72822
Change-Id: I2773ba14fcb24a47fe2ec04860b4aa305a051453
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickItemPrivate::data_append() was not invoked when any kind of
Pointer Handler was directly declared in a Flickable (or subclass)
because QQuickFlickable redefines the default property to be its own
flickableData property. So we need to repeat the special handling
in QQuickFlickablePrivate::data_append() too. The handler must
be added to the private->extra->pointerHandlers vector, so that
QQuickItemPrivate::handlePointerEvent() will attempt to deliver
events to those handlers.
TapHandler seems OK (especially with its default gesturePolicy
so that it does not do an exclusive grab).
PointHandler seems OK.
DragHandler competes with Flickable for the exclusive grab.
pressDelay can help; or set acceptedDevices: PointerDevice.Mouse
to allow the mouse to drag but not flick, and the touchscreen
to flick but not drag.
Fixes: QTBUG-71918
Fixes: QTBUG-73035
Change-Id: Icb97ed5230abe0cb6ec0230b5b5759a0528df7e8
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|\
| |
| |
| | |
Change-Id: Ic746fbce93430867e2eda4bc7155d34e20a4aa2b
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
During a 2-finger press (to emulate right click on a trackpad), the
OS may also generate a QWheelEvent with ScrollBegin phase just in case
scrolling starts. This must not prematurely deactivate the TapHandler.
Also if a gesture or wheel event begins as the very first event after
an application starts, ensure that subsequent mouse events are not
mis-delivered as wheel or gesture events.
Fixes: QTBUG-71955
Change-Id: Ic12e116483ab9ad37c4ac3b1d10ccb62e1349e0a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We already emitted grabCanceled() to inform QML callbacks, but we didn't
call reset(). It seems more proper to do everything that would normally
be done when grab is canceled. TapHandler should not give up its passive
grab yet though, because that prevents delivery to any parent Flickable
that might be filtering events. A parent Flickable should be able to
start flicking after the drag threshold is exceeded (it happens to be
exactly when TapHandler gives up).
Fixes: QTBUG-71466
Fixes: QTBUG-71970
Change-Id: Ibba1b0de92cfd88547eeb44edb095d019de76a94
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
If multiple touchpoints are pressed simultaneously, each point can
be grabbed by one PointHandler instance. Each PointHandler instance
cannot grab more than one point, nor grab a point that is already
chosen by another PointHandler. This was always the intention, but
got broken (perhaps by 3523b676382db4aa39adeb9126d8bb2185e84403),
and there was no test coverage of this case until now.
Fixes: QTBUG-71431
Change-Id: I6d7614eb4767c677d929291f917cf62d9c03bd93
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
QQuickItemPrivate::data_append() was already getting called, but the
assert (that the parent was already an Item) was failing in case a
handler was declared inside a Window or a Dialog.
Fixes: QTBUG-71317
Change-Id: Ia497182e3b4a9722eee97a375f9ee5d4151108e6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If any kind of Pointer Handler is created dynamically in JS by
calling Component.createObject(), QObject::setParent() is called
rather than passing the parent to the constructor, so
QQuickItemPrivate::data_append() did not take care of adding the
handler to QQuickItemPrivate's extra->pointerHandlers vector.
We need to use the auto-parent mechanism (just as we did with
handling dynamic creation of nested Windows in
8cb02e23abbefc9d020707fc1a2d8b6eb4e103b6). Added
QQuickItemPrivate::addPointerHandler() to put the prepend()
and implied setAcceptedMouseButtons() in one place.
Fixes: QTBUG-71427
Change-Id: I3be3dd033c1c89e6e5b5c3463e1a720bbe963281
Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
|
|
|
|
|
| |
Change-Id: I223bad4f8117af76ad2a5079ecc0b73c2eba94bc
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
A QQuickPointerTouchEvent's button and buttons properties are not
currently set (although we had some uncertainty in the past about
whether it would be appropriate for a touch press to simulate a left
button press). So it seems that f2ba3bd9792500b4d3fcfd23b03098a32641ef4f
broke the behavior of PointHandler on touchscreens.
Change-Id: I890cc9889e847636c8f385753e47a078ec582195
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
...and verify the centroid changes in the DragHandler autotest.
It was observable in manual tests that draw velocity vectors that
they weren't getting reset to zero after the release, after
ca7cdd71ee33f0d77eb6bf1367d2532e26155cb2.
Change-Id: I16186d36d51a567b0d653307421147264a5e6326
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, AA_SynthesizeMouseForUnhandledTouchEvents has only affected
behavior of QGuiApplicationPrivate::processTouchEvent, but had no
effect in Qt Quick. QQuickWindow also accepts the touch event
just to make sure that QGuiApplication will not synthesize mouse
from touch, because it would be redundant: QQuickWindow does that
for itself.
Now we make it have an effect in Qt Quick too: skip mouse synthesis
if it is set to false. This provides a way to simplify the
event delivery. If you set it false, then you cannot manipulate old
mouse-only items like MouseArea and Flickable on a touchscreen.
(You can of course use event handlers for that.)
[ChangeLog][QtQuick][QQuickWindow] You can now disable touch->mouse
event synthesis in QtQuick by calling
qGuiApp.setAttribute(Qt::AA_SynthesizeMouseForUnhandledTouchEvents, false);
This will simplify and speed up event delivery, and it will also prevent
any and all interaction with mouse-only items like MouseArea and
Flickable on a touchscreen.
Task-number: QTBUG-52748
Change-Id: I71f1731b5abaeabd9dbce1112cd23bc97d24c12a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
| |
Don't slow down CI for logging unless the test fails.
Change-Id: I2d5faedf3fadb30ec5a732445d695bda7e290233
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Adapted from the PinchArea test.
cancel() does not work, TDB if we want to support that
Done-with: Jan-Arve Sæther <jan-arve.saether@qt.io>
Task-number: QTBUG-69134
Change-Id: I63dfba7b327220b9f032f19c588cc19ebdfd95c2
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
The test is actually flaky without that, but it seems to have been
missing already.
Change-Id: Ic619c66d924c18d3303f1d6bb65d42bc133c56a7
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We always intended to "start over" with event delivery when the number
of touchpoints changes. Change 48011c2dfeb83b4fe717034d4b3c353714fead48
began this process, but in addition to QQuickWindow delivering the
event to all items and their handlers in reverse paint order, ignoring
existing grabs, the handlers themselves have responsibility to act
as if it was an initial press whenever the number of relevant
touchpoints changes; and because QQuickWindow starts over, handlers do
not need to rely on passive grabs to retain interest in one point at
the time when a transition to a different number of points occurs.
For example, DragHandler by default handles just one point, so if you
press one point such that it takes a passive grab and adds that point
to m_currentPoints, then you press a second finger within the bounds
of the same parentItem, the DragHandler should not go on "wanting" the
first point anymore, because a two-finger gesture is different, and
not suitable for the DragHandler unless its maximumPointCount >= 2.
Even if the second point is released, QQuickWindow will "start over"
with delivery, so a multi-point handler does not need to rely on
retaining a passive grab to handle the transition from two points back
to one again.
This also helps enable smoother transitions between different
gestures: e.g. in the map.qml manual test, you can drag one finger and
transition from dragging to pinching and back while the second finger
is pressed, dragged and released.
Change-Id: Id9b8f30029ed1ff9fd2d64a5e413a47055622083
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
..when dragging (translation) is disabled
In order to do this, we had to integrate QQuickAxis to the PinchHandler
which allows enabling/disabling x and y axis individually.
This allows us to have one item with PinchHandler with translation
disabled (but to only handle rotate and scale) together with a two-finger
drag handler.
Change-Id: I1581c575ffba2e5d007163bec36e5699bdd86cbc
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
| |
Ignore buttons which do not fit the acceptedButtons filter, and
do not assume that it's all over when any release happens.
Task-number: QTBUG-66360
Change-Id: I871ea7fdd9b76f06fa0d73382617b287c04d35ab
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is important in order for passive grabbers to be in the same order
as if the points were pressed at the same time.
In our case, the problem occurred when we had a single-point DragHandler
together with a two-finger PinchHandler:
* One finger was pressed and moved
=> DragHandler called setPassiveGrab()
=> point0->passiveGrabbers: [DragHandler]
* A second finger was pressed and moved
=> PinchHandler called setPassiveGrab() for both points
=> point0->passiveGrabbers: [DragHandler,PinchHandler]
=> point1->passiveGrabbers: [PinchHandler]
So then as one keeps on dragging the *two* fingers, the DragHandler will
get the chance to do an exclusive grab first, (since its the first listed
passive grabber of point0), and the PinchHandler won't get the opportunity
to grab. This is not expected since their declaration order implies that
the PinchHandler should get a chance to grab first.
Change-Id: I4e82ed186eeb5bf1dae1679d393e5563072175d1
Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
|
|
|
|
|
|
|
| |
... and clean up imports in examples, snippets and tests accordingly.
Change-Id: I5bbe63afd2614cdc2c1ec7d179c9acd6bc03b167
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
When there's a DragHandler on one Item and a TapHandler on another,
we have more trouble with Flickable stealing the grab. We need a
test to ensure that this problem doesn't reappear after fixing.
Task-number: QTBUG-64846
Change-Id: Ia3bc3b7c9654f09aa96ad70968d82b566686e030
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need Handlers to receive accurate positions for stationary touch
points: that is, the last-known position from the previous touch
event. (And we hope that all actual touch-capable platforms also send
proper QPA events with correct positions for stationary points.
We assert that it's a bug if they don't.)
As explained in qtbase 7cef4b6463fdb73ff602ade64b222333dd23e46c, it's
OK to retain a copy of a QTest::QTouchEventSequence for this purpose,
so that the QMap<int, QTouchEvent::TouchPoint> previousPoints will not
be discarded between events.
We have done this in other tests, but not consistently; e.g.
468626e99a90d6ac21cb311cde05c658ccb3b781 fixed the PinchArea test.
Change-Id: I4dbe69f8dcc4b1cca30fd7ce91d7d2ecf5ec4bc3
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
| |
It was too hard to debug behavior in this test.
Change-Id: Iaec9534cca17bdd90b94cfa8fa8b21b7026839ae
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you want to set target: null and then bind scale to some sort of
rendering scale property directly, it's a lot less trouble if the
scale property does not keep changing back to 1.0 every time a gesture
begins. Added an activeScale property to represent that value, the
one that the scale property had before.
Task-number: QTBUG-68941
Change-Id: Idcb6735d915a523afe1a948609080af7a83f82ad
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
| |
To make grabChanged signal useful, it's necessary to know whether the
Pointer Handler has acquired or lost the grab. This patch fixes that.
Task-number: QTBUG-68074
Change-Id: I29398d2bb5b27b8541197f23c3043ee86cad7c76
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
| |
Change-Id: I08e952fb8c19c21caf33ffb1cfdc260b533a01d9
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>
|
|\
| |
| |
| | |
Change-Id: I64bf7d183bbd8af7282270097809d14a54ba0188
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This got regressed by change e6d4df156e9aec62054740dc99ab8ba2855eaafc. Before
that change, we always cleared both the exclusive and passive grabbers.
Task-number: QTBUG-66152
Change-Id: I93d2568bd2a23ddd55a5294d544f978a50a5543e
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/imports/shapes/qquickshape.cpp
src/imports/shapes/qquickshape_p_p.h
src/qml/compiler/qqmlpropertycachecreator_p.h
src/qml/jsruntime/qv4value_p.h
src/quick/items/qquickloader_p.h
tests/auto/qml/qqmlecmascript/tst_qqmlecmascript.cpp
tools/qmlprofiler/qmlprofilerapplication.cpp
Change-Id: Iafc66ae84bf78630ed72a986acb678e9d19e3a69
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is based on the idea that TapHandler may be more often used to
modify existing behavior rather than building Button controls from
scratch. DragThreshold is reasonable newbie-friendly default behavior
for both use cases. The drag-off-drag-back-release-and-click behavior
is more advanced, and the designers of the best-behaving Button
controls can be expected to discover the need to change gesturePolicy
to get it.
Change-Id: If220acf080e04f664d020d5e832f8d16a16b857a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some Pointer Handlers can perform the desired interaction using only
passive grabs. When such a handler is used to modify behavior of
another event-handling Item or Handler which needs to take the
exclusive grab, this allows them to cooperate: both can see the
updates, and neither prevents delivery of events to both.
Change-Id: I312cc301c52fcdf805245bbe0ac60fd28f92c01f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|/
|
|
|
|
|
|
|
|
| |
Make sure the Rectangles we're sending the touch events to are
visible on screen, otherwise I get consistent failures in this
test on Linux.
Change-Id: Icc2ba7ba73c434dd2ef725adbaa57ab6d413f354
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This helps with overriding behavior: when a QML control implementation
has handlers encapsulated inside, but the user tries to override
behavior by declaring more handler instances in instances of the
control, the user's handlers must be visited before the encapsulated
handlers. Likewise, this reverse-ordering corresponds to intuition
after having used MouseHandlers: the one which is declared last inside
an Item will have a higher effective Z order, and thus will be visited
first during event delivery.
Task-number: QTBUG-64692
Change-Id: I9bf18218a1887d0297c71ebf81dde0956394b72a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
| |
Change-Id: Ib1fe267c23ea9fce9bcc0a91ed61081260338460
Reviewed-by: Liang Qi <liang.qi@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
even if all points are accepted or grabbed. A passive grab isn't much
good if there are cases where the handler is prevented from monitoring.
This enables e.g. the PinchHandler to steal the grab when the right
number of touchpoints are present and have moved past the drag threshold,
and enables completion of a couple of autotests.
Change-Id: I78dc6fc585f80bfb3c13e0c6e757ef815fb94afe
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
setGrabberPointerHandler is now implemented more similarly to
setGrabberItem. One improvement is that in
tests/manual/pointer/pinchDragFlingMPTA.qml the MPTA deactivates
when the PinchHandler takes over its touchpoint grabs.
Change-Id: I0bd4f143b5f25f1b393839f86c2a7802f1fa1886
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an item that had a TapHandler and a DragHandler was placed inside a
Flickable it would call sendFilteredPointerEvent() for each of the
handlers, even if they were siblings.
This is not ideal, and because of a mechanism in flickable it even caused
the DragHandler to not drag the item as expected.
This is because of a mechanism in Flickable where the value returned is
actually derived from the previous call to filterMouseEvent() (stored in
member variable stealGrab).
Below are the relevant steps it went through when the mouse drag exceeded
the drag threshold (mouse pointer started on the item):
Precondition: QQuickFlickablePrivate::stealMouse == false
1. Mouse Drag (which exceeded drag threshold)
2. sendFilteredPointerEvent(tapHandler->parentItem()) returns false.
(but since it moved beyond threshold, it would set stealGrab-> true).
3. tapHandler->handlePointerEvent() declined and ungrabbed (due to
DragThreshold gesture policy).
4. sendFilteredPointerEvent(dragHandler->parentItem()) returns true
(because the previous call to sendFilteredPointerEvent() set stealGrab
to true).
As a consequence of (4), dragHandler->handlePointerEvent() was not called,
and the flickable would start to flick instead of the item starting to drag.
Change-Id: Ia99eae91cad0903ebbaedaaafcdf92a25705a922
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
This is more flexible in case someone wants a PinchHandler to respond
in the same way for either 2 or 3 touchpoints, for example.
Change-Id: I360ce6f0239d86aa92dbebc225e3646883e71100
Reviewed-by: Jan Arve Sæther <jan-arve.saether@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>
|
|
|
|
|
|
|
|
|
| |
This is for the sake of convention. Unfortunately (and the reason
it wasn't done this way at the outset), it may prevent us from ever
having a signal called "pressed" in this handler or its base class.
Change-Id: Iafa117410e0e33562290b87df59bc8c0085c217d
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
Conflicts:
examples/quick/shared/LauncherList.qml
src/quick/items/qquickevents.cpp
src/quick/items/qquickevents_p_p.h
src/quick/items/qquickwindow.cpp
tests/auto/quick/touchmouse/tst_touchmouse.cpp
Change-Id: Id692d291455093fc72db61f1b854f3fc9190267b
|
|
|
|
|
| |
Change-Id: Ia67dd04333a7879362819e1bb2a891c1f92b7069
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
| |
Change-Id: I46f7e2c16b775723a08aa192845d490046231990
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
| |
to test interoperability of PointerHandlers with conventional touch-
handling Items (with MultiPointTouchArea being the prototypical instance)
Change-Id: Id19f312b17b70df072d66cd91816d2b19250a500
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|