| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, starting a mouse drag outside a DragHandler's parent and
moving inside would activate it. This is unexpected behavior,
inconsistent with touch behavior, and might interfere with other drags,
so we only activate a DragHandler if at least one point was pressed
inside the parent.
Pick-to: 6.10 6.9 6.8
Fixes: QTBUG-127863
Change-Id: I2215636397ce9fc6a29b9a35165507e5b8d886f4
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These should already behave the same with much-older Qt versions:
so far, multi-point handlers require all points to be pressed inside the
parent Item.
Although DragHandler has long supported setting minimumPointCount to
require more than one finger, we didn't have test coverage for that.
So far the main "real" use case is the 2-finger tilt gesture in maps
(in which case target is null), but it can also be used for dragging
a target with more than one finger.
Pick-to: 6.10 6.9 6.8
Task-number: QTBUG-127863
Change-Id: I2d4734f12a31a4b720bd11c05a61bc0cdc3b84ce
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, DragHandler didn't account for scene transforms when
calculating drag threshold. In the case when one axis is disabled,
and the scene is rotated 90 degrees, the remaining axis should be
activated by movements that are nominally the same as the disabled
direction, because of rotation.
Fixes: QTBUG-136354
Pick-to: 6.8 6.9
Change-Id: I6669949908b0d026850411c10056685648a109d9
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
| |
QTest::createTouchDevice() passes ownership of the device to the caller,
so make sure it gets deleted.
Pick-to: 6.8 6.9
Change-Id: I1289def6b40bf688a7334b9997f7e4319516d018
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Never use module-wide inclusions. They blow up build times. For QtTest
this is usually just a typo (QTest was meant instead). Add missing
includes as needed.
In the diffs I've spotted other huge inclusions (QtQuick, QtQml), but
those need more attention.
Task-number: QTQAINFRA-7110
Pick-to: 6.9 6.8
Change-Id: I74bf3fe212f50a7a3a6af2b1c80bbcaabc2516d7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickDragHandler::handlePointerEventImpl() accepts the event to begin
with. Since ca7cdd71ee33f0d77eb6bf1367d2532e26155cb2 we meant to stop
event propagation for mouse events, at least to prevent Flickable from
receiving the event via direct delivery after it has already filtered.
But back then, QEvent::setAccepted() did not automatically accept the
touchpoints; now it does (a questionable choice in Qt 6 that accept()
and setAccepted(true) do not do the same thing).
Now we leave QEventPoint:isAccepted state alone if it's a touch event,
so the workaround to stop propagation of mouse events is the only case
where it needs to be changed. And update the comment: since
3073a81e90c8d835dfccccf8b3a080a93ed0d2af Flickable handles touch events
directly, it doesn't depend on touch->mouse synthesis.
Fixes: QTBUG-124731
Pick-to: 6.8 6.7
Change-Id: I833a4d28f708e27cf01b108da1b886807725dc06
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to QUIP-18 [1], all test files should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: I26d72e8de04d4c7c57b3b7838af5d033265de5ba
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All these TUs relied on transitive includes of qpointer.h, maybe to a
large extent via qevent.h, though, given that qevent.h is more or less
the only public QtBase header that includes qpointer.h, something else
seems to be at play here.
Said qevent.h actually needs QPointer in-name-only, so a forward
declaration would suffice. Prepare for qevent.h dropping the include.
The algorithm I used was:
If the TU mentions 'passiveGrabbers', the name of the QEvent function
that returns QPointers, and the TU doesn't have qpointer.h included
explicitly, include it. That may produce False Positives, but better
safe than sorry. Otherwise, in src/, add an include to all source and
header files which mention QPointer. Exception: if foo.h of a foo.cpp
already includes it, don't include again.
Task-number: QTBUG-117670
Change-Id: I9b98cda524a0e6a61be7805edda708916bb2bc2b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
| |
- Sometimes you just need to see the touchpoints and centroids
- Delay long enough to see them
- Avoid QTRY_COMPARE when we're sure the event was already flushed
- Fix indentation
Pick-to: 6.5
Change-Id: I307963378c29fb285190657e7a0693888ad7c48c
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the intention is that a handler should react only to the left mouse
button (by default, acceptedButtons == Qt.LeftButton), and the user
presses the right button while the handler is already active, it
de-activates, because wantsPointerEvent() returns false. But now it will
no longer emit canceled() in that case. The docs for the canceled signal
say "If this handler has already grabbed the given point, this signal is
emitted when the grab is stolen by a different Pointer Handler or Item."
But in this case the handler gives up its grab voluntarily, it's not
being stolen by anything else.
Probably we were emitting canceled because it's intuitive that the
gesture is being canceled because something weird happened. But that's
not the documented reason for emitting this signal, and it's perhaps
inconsistent with the fact that dragging can be resumed.
The mechanism for emitting when another handler or item takes over the
grab begins in QPointingDevicePrivate::setExclusiveGrabber(), which
emits grabChanged(), which is connected to
QQuickDeliveryAgentPrivate::onGrabChanged(), which will call
onGrabChanged() on the handler, and the base class implementation
QQuickPointerHandler::onGrabChanged() will emit canceled(). At least in
this case a handler does not need to decide on its own to emit.
[ChangeLog][QtQuick][Event Handlers] A Pointer Handler no longer emits
the canceled() signal when it deactivates due to violating conditions
(such as pressing the right button when acceptedButtons == LeftButton).
Fixes: QTBUG-102201
Pick-to: 6.5
Change-Id: Ibe67c8f2a5e44d96df3a788ca1ee4e43f7de658d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
This should've been ok after qtbase 1fdbbb49d9f2d2bb62e151a29e5615031af6606a
Pick-to: 6.2 6.4
Task-number: QTBUG-33891
Change-Id: I96cba3bc2fb8c0dd3e1411d56f81ccfcd1e0947f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PinchHandler.scale is persistent between gestures, whereas rotation and
translation were active-gesture properties; that wasn't consistent.
We fixed up DragHandler in just this way in 6.2.
The translationChanged() signal now comes with a vector delta, which is
often useful when writing an onTranslationChanged JS handler. Likewise,
scaleChanged() and rotationChanged() come with qreal deltas. The
scaleChanged() delta is multiplicative rather than additive, because
an additive delta would not be useful in cases when some target item's
scale can be adjusted by alternative means: you need to multiply it
in your onScaleChanged function.
Now that PinchHandler has 4 axes as grouped properties, some properties
in the handlers themselves begin to look redundant; but at least the
translation properties are useful to group x and y together. So in this
patch we continue to follow the pattern that was set in
60d11e1f69470d588666b76092cd40ae5644a855. PinchHandler.scale is
equivalent to persistentScale, whereas rotation is equivalent to
activeRotation; so we have a reason to deprecate those properties, as in
ea63ee523377bd11b957a9e74185792edd9b32e8.
The persistent values have setters, to provide another way for
applications to compensate when the values are adjusted by other means,
as an alternative to incremental changes via a script such as
rotationAxis.onValueDelta, onRotationChanged etc.
[ChangeLog][QtQuick][Event Handlers] PinchHandler.activeTranslation now
holds the amount of movement since the pinch gesture began.
PinchHandler.persistentTranslation holds the accumulated sum of
movement that has occurred during subsequent pinch gestures, and can
be set to arbitrary values between gestures. Likewise, activeScale,
persistentScale, activeRotation and persistentRotation follow the
same pattern. The scaleChanged, rotationChanged, and translationChanged
signals include delta arguments, which are useful for incrementally
adjusting a non-default item property when the target is null.
Fixes: QTBUG-76739
Task-number: QTBUG-94168
Change-Id: I6aaa1aa3356b85e6d27abc64bfa67781ecb4f062
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pointer Handlers that manipulate target item properties should now
use QQuickDragAxis consistently to:
- enforce minimum and maximum values
- hold the persistent and active values
- make those available via properties
- emit a new activeValueChanged(delta) signal when the value changes,
so that it's possible to incrementally update a target item
property in JS (onValueDelta: target.property += delta)
In the pinchHandler.qml example, you can use the PinchHandler to adjust
4 properties of one Rectangle independently (it requires coordination).
m_boundedActiveValue controls whether m_activeValue will be
kept between minimum and maximum. For rotation,
tst_QQuickPinchHandler::scaleNativeGesture() expects it to be,
although that seems questionable now, and may be addressed later.
[ChangeLog][QtQuick][Event Handlers] PinchHandler now has scaleAxis and
rotationAxis grouped properties, alongside the existing xAxis and yAxis;
and all of these now have activeValue and persistentValue properties.
The activeValueChanged signal includes a delta value, giving the
incremental change since the previous activeValue. The persistentValue
is settable, in case some target item property can be adjusted in
multiple ways: the handler's stored value can then be synced up with the
item property value after each external change. These features are
also added to DragHandler's xAxis and yAxis properties.
Task-number: QTBUG-68108
Task-number: QTBUG-76380
Task-number: QTBUG-76379
Task-number: QTBUG-94168
Change-Id: I78a5b43e9ba580448ef05054b6c4bc71b1834dd6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The referenced bug report specifically complained about warnings caused
by including qquickpointerhandler_p.h. All of those -Wshorten-64-to-32
warnings come from headers that aren't strictly needed for
qquickpointerhandler_p, though.
So fix the issue by only including what is actually need, which also
slightly improves compile times. This requires adding a few transitive
includes in select places.
As a drive-by, remove the unneeded QML_DECLARE_TYPE.
Fixes: QTBUG-105055
Change-Id: I24d78e7131771a4bbcb402e6838a5a9a11abbbec
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8:
auto QtContainerClass = anyOf(
expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o),
expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o));
makeRule(cxxMemberCallExpr(on(QtContainerClass),
callee(cxxMethodDecl(hasAnyName({"count", "length"),
parameterCountIs(0))))),
changeTo(cat(access(o, cat("size"), "()"))),
cat("use 'size()' instead of 'count()/length()'"))
a.k.a qt-port-to-std-compatible-api with config Scope: 'Container',
with the extended set of container classes recognized.
Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Protect the usage of deprecated APIs by #ifdefery, and also suppress
the deprecation warnings for it. Add tests for the replacement APIs.
In tst_multipointtoucharea_interop simply replace the deprecated
API with the new one.
This allows to build the tests without deprecated APIs.
Task-number: QTBUG-104858
Change-Id: I017e64ca467455decd6c663240225de69acebec1
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously each test would include and build sources from the shared
folder. Now we make those sources a library, build it once, then have
each test link to it instead.
We also take the opportunity to move some helpers that qtquickcontrols2
had added into the quicktestutils library where it makes sense, and
for the helpers that don't make sense to be there, move them into
quickcontrolstestutils.
We add the libraries to src/ so that they are internal modules built as
part of Qt, rather than tests. That way we can use them in a standalone
test outside of qtdeclarative.
Task-number: QTBUG-95621
Pick-to: 6.2
Change-Id: I0a2ab3976fdbff2e4414df7bdc0808f16453b80a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you want to set target: null and then bind translation to some
object's x and y properties directly (perhaps an Item, a Qt Quick 3D
Model object, etc.), it's a lot less trouble to use a translation
property that does not keep changing back to 0,0 every time a gesture
begins. In hindsight, the translation property should have been the
persistent one (for consistency with the fix for QTBUG-68941,
in which we made PinchHandler.scale persistent and added activeScale:
b4d31c9ff5f0c5821ea127c663532d9fc2cae43e). But for several years, the
translation property has been restarting with each gesture; so now we
add a persistentTranslation property. The new activeTranslation property
has the same value as the translation property (which is deprecated).
Also, the persistentTranslation property is settable, because
in some UIs there may be multiple ways to move the same object,
and there needs to be a way to sync them up.
Also fixed a bug: when minimumPointCount == 2,
QQuickMultiPointHandler::wantsPointerEvent() doesn't initialize
d->currentPoints until two points are pressed. But often, one point is
pressed, and in the next event, the second point is pressed while the
first is held Stationary. So QQuickHandlerPoint::reset() needs to set
pressPosition and scenePressPosition on both points at the same time,
because it is called on each HandlerPoint in d->currentPoints at that
time when both points are pressed. So if any point is pressed, act as if
they all were freshly pressed. Without this fix, the centroid's
scenePressPosition is wrong (based on the average of 0,0 and the second
point), therefore a "jump" was occurring when persistentTranslation
is used to directly drive a binding (like the tilt in map.qml).
[ChangeLog][QtQuick][Event Handlers] DragHandler.activeTranslation now
holds the amount of movement since the drag gesture began.
DragHandler.persistentTranslation holds the accumulated sum of
movement that has occurred during subsequent drag gestures, and can
be set to arbitrary values between gestures.
Task-number: QTBUG-94168
Change-Id: I1b2f8ea31d0f6ff55ccffe393bc9ba28c1a71d09
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As explained in the comment, the handler can override the keepMouseGrab
"veto" if the item is a parent (like a Flickable) that filters events,
but not in other cases. The logic was wrong though, apparently.
Amends 090f404cf80da35734f712b02cc1543acecd5b62
Pick-to: 5.15 6.1
Fixes: QTBUG-78258
Task-number: QTBUG-79163
Change-Id: I9a473ab3b23743f863cb0be13767fdbc29cd5e1c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickPointerHandler::handlePointerEvent() calls setActive(false)
when wantsPointerEvent() returns false (except for a NativeGesture
event), for the sake of deactivating reliably when it receives an
event which it does not handle. Now we need one more exception, because
it's not what we want in DragHandler while dragging: If we get a
wheel event, that should not interrupt the current drag operation.
Thus, we change the logic in wantsPointerEvent to consider even events
we wouldn't normally handle while the DragHandler is active.
In handlePointerEventImpl, we then simply ignore them.
Fixes: QTBUG-91549
Pick-to: 6.1 5.15
Change-Id: I24e8bd890a21b244c9964f4df76986688085fa87
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
| |
Change-Id: I13da0d085901314950c4fa0afb5853e183652e67
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After qtbase b50daef9771d8829fc7f808898cbe051a5464b79, a mouse move
event that does not contain a mouse location different than the last
known location is no longer delivered.
It's intended to be OK to set DragHandler.threshold to 0, and this test
was checking functionality in that case; but we now need to move the
mouse at least one pixel to test it. Then, the drag threshold is
immediately exceeded, the drag begins, translation starts to occur, etc.
Amends ab5df626bef9365089ce716ce476bccae1d0a04b
Task-number: QTBUG-85431
Change-Id: I89c0dc13ed06fbf1443f42fa5b63713da56ecf6d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a PointerHandler with a custom cursor deactivates, the cursor
wasn't restored until the next mouse move.
I was writing a test to ensure that there were no bugs analogous
to QTBUG-85303 with a handler that uses its active state to change
the cursor (unlike HoverHandler which changes it whenever the
mouse is hovering) and found this new bug.
Pick-to: 5.15
Fixes: QTBUG-85325
Task-number: QTBUG-85303
Change-Id: I4ea8dbd267046c8e972e723cc491bd44bbbfd7f2
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, QQuickItemPrivate::setHasCursorInChild() was unable to check
the QQuickItemPrivate::hasCursor variable, because the function
argument hasCursor was shadowing that, even though the comment
"nope! sorry, I have a cursor myself" hints that the intention
was to check that. So this change exposed a problem there, and
we have to fix that too, in order to keep the tst_qquickwindow::cursor()
test passing.
[ChangeLog][Event Handlers] Pointer Handlers now have a cursorShape
property to set the cursor when the handler is active and the mouse is
hovering, and restore to the previous cursor when the mouse leaves.
Fixes: QTBUG-68073
Change-Id: Ib5c66bd59c4691c4210ee5465e1c95e7bdcf5ae1
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need drag threshold to be adjustable on each handler instance instead
of relying only on the system default drag threshold. For example in
some use cases DragHandler needs to work with a threshold of 0 or 1 to
start dragging as soon as the point is pressed or as soon as the point
is moved, with no "jump", to enable fine adjustment of a value on some
control such as a Slider.
This involves moving the dragOverThreshold() functions that handlers are
using from QQuickWindowPrivate to QQuickPointerHandlerPrivate, so that
they can use the adjustable threshold value.
Task-number: QTBUG-68075
Change-Id: Ie720cbbf9f30abb40d1731d92f8e7f1e6534eeb5
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/quick/handlers/qquickpointerdevicehandler.cpp
src/quick/scenegraph/qsgdefaultglyphnode.cpp
src/quick/scenegraph/qsgdefaultglyphnode_p.cpp
src/quick/scenegraph/qsgdefaultglyphnode_p_p.h
tests/auto/qml/qjsengine/tst_qjsengine.cpp
Done-With: Jan Arve Sæther <jan-arve.saether@qt.io>
Done-With: Laszlo Agocs <laszlo.agocs@qt.io>
Change-Id: I35749152f8dce44b9af8d52b1283629879010f11
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reverts what's left of e53510944169ac9f6753e0d14e1b24a24ff7bd9a
(amends 73258eca7ab7e3981d9f4aaa5484020cb67854a0):
MultiPointHandler is not only for touch handling anymore.
DragHandler in particular needs to respect the acceptedButtons property.
Fixes: QTBUG-76875
Fixes: QTBUG-76582
Change-Id: I414e785dd09b297c93e5e9f162be23e4a44eca54
Reviewed-by: Jan Arve Sæther <jan-arve.saether@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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not being pressed inside the target is a necessary but not sufficient
reason to reset m_pressTargetPos to the center of the target. The
intention was rather to make the target jump into position when the
parent was a different item: e.g. if a Slider has a DragHandler whose
target is the slider's knob, you can start dragging anywhere on the
whole Slider but you want the knob to jump to the cursor position when
the drag begins.
While we're at it, both branches of the if in onGrabChanged()
are checking that target() isn't null, so we can move that check out.
Fixes: QTBUG-74966
Change-Id: I05be11d27422b070d941b9e43d4e1157e071c3a5
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This happened if you moved the mouse while doing a multitouch operation.
More specifically this caused the bug:
1. Open qtdeclarative/tests/manual/pointer/map.qml
2. Rotate the map with two fingers (Do not release fingers).
3. Move mouse (no buttons pressed).
4. Release both fingers.
5. Move mouse again (error: the draghandler has a grab and thus the map is
dragged even if no buttons are down).
This happened because if you moved the mouse while having two fingers
down, Windows would generate a *mouse*move* event with Left button or Right
button pressed (which wasn't the case on the physical device but it's
probably because of a bug in how mouse events are synthesized from touch
on Windows). This caused the QQuickMultiPointHandler to do a passive grab.
Then, when releasing the fingers it would not send a mouse release event
(just plain touch release events), so the QQuickMultiPointHandler would
keep the passive grab it had.
All subsequent mouse move events would then be dispatched to the
QQuickMultiPointHandler where it would assume that the button was pressed
until it got a release event (but button was never pressed so that
wouldn't happen). Eventually it would perform an exclusive grab, and
dragging was initiated.
Change-Id: I42b3133c5fde93c7f92f1cb28705156a69f9ad1c
Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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>
|
|
|
Change-Id: I46f7e2c16b775723a08aa192845d490046231990
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|