| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
This could for instance happen if the window gets exposed under the
cursor, and it sends a mouse move event that might interleave the press
and release events, causing the eventCount variable to jump to 3.
Change-Id: Icce59b2aa1a937a990baa83f503907633003e2bb
Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
to verify when a point is pressed on a PointerHandler, dragged outside,
and released, the handler gets a release event, or a cancel.
Change-Id: Icdcb67c5549aca605bc6e7b425978760330ba270
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
| |
Now an Event could represent a QEvent, a PointerEvent, or a call to onGrabChanged,
so we can test the sequence more thoroughly.
Change-Id: Ib935cda8dfc87c37d917989423615688dc9c260c
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
| |
Change-Id: I1e0539fe24e19ca15641fa4007488b33c24ab8ba
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's now standard practice in autotests to use QScopedPointer to
manage the window so that it doesn't need to be deleted (or would be
left dangling if the test fails).
It's nice to be able to see the bounds of the EventItem.
Test not only the order of the event types received, but
the EventPoint state, and where they were received.
Of course PointerEvents go only to PointerHandlers in this test so
far... but now we can distinguish filtered events from events which
were received via the QQuickItem virtual function overrides.
Change-Id: I4830a431bedb7101c8c980ab3260d23b5852b645
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
Add documentation to the grab-related event and eventpoint methods.
Rename "grabber" functions which relate only to the exclusive grab,
in cases where it would otherwise be ambiguous.
And a few other documentation changes.
Change-Id: I1a203c8c06a19d4abdb000f08b387c38341ef476
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now if a Button with a TapHandler is pressed and has only a passive
grab, Flickable can take the exclusive grab, and it notifies the
TapHandler so that the button can go back to released state.
This reverts parts of commit e2fd141372335f917c2d216051abb00d8b15f87c
such that more of tst_PointerHandlers is working the same as it was
before we started adding the passive grab concept.
Change-Id: I88970716fcbbfb066a313fcefb233cf9263da944
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
| |
Change-Id: I4a6e3c72d69e893fec2e39f4faab24af6d00c7e0
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If no handler or item accepts a newly-pressed point, the event will be
re-delivered in deliverTouchEvent(). It doesn't make sense to
re-deliver to the same handlers though.
A temporary QSet isn't cheap to create, whereas it seems we will need
to keep track of handlers which have already been visited, in order to
avoid visiting passively-grabbing handlers multiple times. Since both
a QVector and a QSet are heap-allocated, and we expect to have a limited
quantity of handlers grabbing at one time, a retained QVector (cleared
between events) seems to be the cheapest data structure.
Change-Id: I831e9a2576b2fcb9095e065795f2baff58115a49
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
The "weak grab" concept depends on this.
First we deliver to grabbers, then we deliver to non-grabbing handlers
(but not to non-grabbing items). Avoid re-delivering to grabbing
handlers which already received the same event.
Change-Id: If51e1cd9372e3bed1daea3758e9ef8e37c0ba5e3
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
Tests will become too complex to do them all in one class, so let's
have a subdirectory for each handler.
Change-Id: I157f6c150f15ca53d77bc9eb716723c6105e393a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
|
