| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Followup to 1457df74f4c1d770e1e820de8cd082be1bd2489e : if an item that
has acceptTouchEvents() == true merely fails to accept one touch event,
that does not mean a mouse event should be sent.
Finish changing the default to false: handling touch events is opt-in,
just like handling mouse events; most items don't. And if you opt in,
then you MUST handle touch events, because you will NOT receive mouse
events as a fall-back.
Now that Flickable handles touch, filtering multi-touch events becomes
relevant. There was a failure in tst_touchmouse::mouseOnFlickableOnPinch
when Flickable grabs a stationary touchpoint at the same time as another
touchpoint is pressed, preventing a child PinchArea from reacting.
So there's a new rule: just as we start over with event delivery when a
new point is pressed, QQuickFlickable::filterPointerEvent() should also
not immediately grab when any point is newly pressed; it can afford to
wait, because it's filtering, so it will be able to see if one point is
dragged past the drag threshold later on.
When a parent (such as Flickable) contains only mouse-handling items
(such as MouseArea), the parent should filter the touch event if it is
able (if acceptTouchEvents() returns true). Flickable is now able to.
Filtering parents that are not able to filter touch events can still
filter a synth-mouse event as before. But filtering both must be
avoided: then we would have the problem that Flickable filters a touch
move, sees that it's being dragged past the drag threshold, and sets
d->stealMouse to true to indicate that it wants to steal the _next_
event; then it filters a synth-mouse move, and that's perceived as being
the next event even though it's just a different view of the same event,
so it steals it. In tst_qquickflickable::nestedMouseAreaUsingTouch we
rely on the delay caused by waiting for the next event: the MouseArea is
trying to drag an item and the Flickable wants to flick; both of them
decide on the same event that the drag threshold is exceeded. But
MouseArea calls setKeepMouseGrab() immediately, whereas Flickable
doesn't try to steal the grab until the next event, and then it sees the
keepMouseGrab flag has been set, so it doesn't do it. If Flickable
could filter the same event twice (once as touch, once as synth-mouse),
this logic doesn't work, so it's effectively "more grabby" than
intended. So it works better to have it filter only the actual touch
event, not the synth-mouse that comes after.
When the child has pointer handlers, we need to visit them, and
therefore we should let Flickable filter a touch event on the way.
tst_FlickableInterop::touchDragFlickableBehindButton() depends on this.
[ChangeLog][QtQuick][QQuickWindow] In Qt 6, a QQuickItem subclass must
explicitly call setAcceptTouchEvents(true) to receive QTouchEvents,
and then it must handle them: we no longer fall back to sending a
QMouseEvent if the touch event is not accepted. If it has additionally
called setFiltersChildMouseEvents(true), then it will filter touch
events, not any synthetic mouse events that may be needed for some
children.
Task-number: QTBUG-87018
Fixes: QTBUG-88169
Change-Id: I8784fe097198c99c754c4ebe205bef8fe490f6f4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| |
|
|
|
|
|
|
|
| |
In Qt 6, setAcceptTouchEvents(true) must be done explicitly for an
item to receive touch events.
Task-number: QTBUG-86729
Change-Id: Ib18db22b6a7213dfcfdf091d554ef60fbede6111
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| |
|
|
|
|
|
|
| |
PointerHandlers see more events now.
Task-number: QTBUG-86729
Change-Id: I4dbddc8b54292450cf5ffb77489178a8a824b90d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| |
|
|
|
|
| |
Task-number: QTBUG-86729
Change-Id: I47a0a4aad7cff956b2ebd450870d625f817690d4
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It's a cosmetic change at this time, because we have declared
using TouchPoint = QEventPoint;
Also replace Qt::TouchPointState enum with QEventPoint::State.
Task-number: QTBUG-72173
Change-Id: Ife017aa98801c28abc6cccd106f47a95421549de
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
...and generally deal with changes immediately required after adding
QInputDevice and QPointingDevice.
Also fixed a few usages of deprecated accessors that weren't taken
care of in 212c2bffbb041aee0e3c9a7f0551ef151ed2d3ad.
Task-number: QTBUG-46412
Task-number: QTBUG-69433
Task-number: QTBUG-72167
Change-Id: I93a2643162878afa216556f10808fd92e0b20071
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several event accessors were deprecated in
qtbase/24e52c10deedbaef833c0e2c3ee7bee03eacc4f5.
Replacements were generated by clazy using the new qevent-accessors check:
$ export CLAZY_CHECKS=qevent-accessors
$ export CLAZY_EXPORT_FIXES=1
$ ../qt6/configure -platform linux-clang -developer-build -debug
-no-optimize-debug -opensource -confirm-license -no-pch QMAKE_CXX=clazy
$ make
$ cd ../../qt6/qtdeclarative
$ find . -name "*.clazy.yaml"
$ clang-apply-replacements .
Task-number: QTBUG-20885
Task-number: QTBUG-84775
Change-Id: I1be5819506fd5039e86b4494223acbe193e6b0c9
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
| |
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>
|
