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>
- FakeFlickable was moved in 8503f884bb
but this still needs it, so we just copy it back (unmodified)
- use QtQuick.Dialogs version of FolderDialog
- improvements from qtdoc 489e346f37fbf31b0034f0e80fcd97e87c2e0304 and
following patches
The FolderDialog may not open because of QTBUG-111564.
Setting XDG_CURRENT_DESKTOP=GNOME helps.
Task-number: QTBUG-108924
Task-number: QTBUG-111564
Change-Id: I15972d3df2b1a2a01cd91361ab2c8b44a40c93a1
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>
They were always meant to be examples eventually. Now they will be used
for an example of how to implement custom controls using only basic
items and handlers. Some components are very similar to those in
the shared directory; but most examples will use Qt Quick Controls,
so those shared components can be removed when we no longer use them.
This example should remain as the one that shows how to build
reusable controls "from scratch".
Removed InputInspector because it's inefficient, has limited usefulness,
tends to require building the manual test to be able to run it, and
could be better built as a reusable Qt.labs component later on,
providing a model with all known devices and taking advantage of the
QPointingDevice::grabChanged signal to track the grab states rather
than polling.
Pick-to: 6.2
Change-Id: I47ab6ebb2cecab07a69cf96e546ffd0db3026a60
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
It's still MIA. Material style has its own implementation but we
unfortunately aren't shipping any module with a reusable RectangularGlow.
Pick-to: 6.1 6.2
Change-Id: Ie14188c517ff31217e25dc428b400659e3d0613f
Reviewed-by: Shawn Rutledge <shawn.rutledge@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:
b4d31c9ff5). 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>
In Qt 5 the numbers were smaller, as if units were pixels per millisecond.
In Qt 6 it hopefully really is in logical pixels per second; so the
animation destination should be divided by 1000 relative to what it was before.
Likewise the velocity arrow in flingAnimation.qml should be 1000x shorter.
This looks and feels about right currently.
Fixes: QTBUG-93886
Change-Id: I7b8039024bff11f1a65a2f02ac5e2d85654cbdd0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
It can be used to change any qreal property of its target Item in
response to wheel rotation, or it can be used in other ways that involve
bindings but without a target item.
[ChangeLog][QtQuick][Event Handlers] Added WheelHandler, which handles
mouse wheel rotation by modifying arbitrary Item properties.
Fixes: QTBUG-68119
Change-Id: I247e2325ee993cc1b91a47fbd6c4ba0ffde7ad49
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
The main reason is that the drawer also demonstrates a different use
of the BoundaryRule (limiting drags, with springy endstops).
Change-Id: I958af65a857fda1b5b8dc1b135414799261afc1f
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>
... and clean up imports in examples, snippets and tests accordingly.
Change-Id: I5bbe63afd2614cdc2c1ec7d179c9acd6bc03b167
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
It's not just useful for PinchHandler: TapHandler has a good use for it
too. But unfortunately if the handler's parent Item has a custom mask,
we don't have a way to augment the mask with a margin; so if margin is
set, we assume the bounds are rectangular.
QQuickMultiPointHandler::eligiblePoints() now calls wantsEventPoint()
rather than bounds-checking the point directly: this adds flexibility,
potentially allowing an override in subclasses, if we need it later.
Task-number: QTBUG-68077
Change-Id: I65c95f00c532044a5862654e58c9c5f8c973df81
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We already had a manual test using a slider, but that has only
one combination of DragHandler and TapHandler.
This test aims to test all possible combinations of DragHandler and
TapHandler together (as siblings, in different parts of the hierarcy,
with a Flickable beneath...)
We also show the current grabbers as an overlay over this entire
collection of manual tests.
Change-Id: Ic634d36d14f7456170f43b077fa72b03fb65bc18
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>
If you flick in such a way that y is within bounds but x is out of
bounds, then returnToBounds should not change y; and vice-versa.
Change-Id: I156a2f6e28bdcd6aecce35e639acaa05e55ee382
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
It looks much nicer than just jerking back into position.
We still don't have "resistance" to dragging past the bounds, though.
Change-Id: I60f6f58fe87638fd17144ea6640bae673a3b633d
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>
It demonstrates that DragHandler's grabs work well enough, so that
you can grab the knob and drag it even while the cursor goes outside
the window. Also the TapHandler for detecting clicks or taps within
the "trough". And for completeness, the FakeFlickable example
needed scrollbars, to prove that it's possible to build all the
flicking and scrolling behaviors with only PointerHandlers.
Change-Id: I9d9323b1f583a02e0157edb85b6bffbe1652711f
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Missiles are too expensive to launch in continuous sprays anyway.
Also, it's too hard to keep holding down the "balloons" button if
we use policy DragThreshold. This is better to have on the
fighters button, since the usual use case is that ballons are
launched first, and cheap enough to launch continuously.
Change-Id: I3b52556b81afad9fb7ec1a4b1dec4dde3bab104c
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Until now it behaved as if this was set to DragThreshold: give up on
the tap as soon as you are clearly dragging rather than tapping.
But that's not what is normally wanted when building a Button control,
for example. So provide 3 options: give up past the drag threshold,
when the pointer goes outside the bounds, or when it's released
outside the bounds. The longPressThreshold also constrains all
three cases: holding (or dragging) for too long will not result
in an immediate cancellation, but it also will not be a tap gesture.
Change-Id: I95aec978e783892b55371391a27642751d91d9ff
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
to verify that Flickable still works after the changes in event
delivery logic, even when it contains a mix of various Areas and Handlers.
Change-Id: Ibf68bc8b403718c87c7e647b17837f2a8e4e3f0e
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Demonstrate that DragHandler, MomentumAnimation and a couple of Items
are enough to implement most of Flickable's functionality.
Change-Id: I59dae38dc66c16813385aa6c00e3a1a834520f31
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
It could be exposed as a new type of animation, but for now it's just
an experiment.
Change-Id: Ic900752a90ccae93270e27399f370f5d47495f74
Reviewed-by: Jan Arve Sæther <jan-arve.saether@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>
A handler for dragging Items around by touch or mouse.
Change-Id: Id83fea568095eb6374f3f1abc6f550d81f3731df
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
Lucie Gérard
Shawn Rutledge
Jan Arve Saether
Kai Koehne