- reserve the borderBlink feedback for these signals: the flashAnimation
feedback is enough to show the regular tapped signal
- make the flashing border more obvious: wider on a lighter background
- make the border even wider for a double-tap
- just blink once; the 3-blink animation looked nice, like classic
macOS, but was a bit disorienting if you are tapping multiple times
and trying to count which signals got emitted
- stop the animation before starting the double-tap animation, to avoid
missing it: usually the double-click interval is less than 500ms
Followup to d3f2c6ac42
Task-number: QTBUG-65088
Task-number: QTBUG-107264
Pick-to: 6.5
Change-Id: Ia2f78a7d1e758fc717078b6aa44a0f6716afd227
Reviewed-by: Matthias Rauter <matthias.rauter@qt.io>
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@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>
On a touchscreen, right-clicking is not directly possible; so sometimes
a long-press gesture is used as a substitute. The next thing a UI
designer would want would then be a way of showing feedback that a
long-press is in progress, rather than simply waiting for the long-press
to occur and then surprising the user with some instant action.
For example, a menu might begin to open as the user holds down the
touchpoint; but before the long-press gesture is complete, the user can
simply release, to cancel the gesture and close the menu. The timeHeld
property could drive the animation, to avoid needing a separate
animation type; in fact the reason timeHeld exists is to make it easy
to emulate this sort of touch-press animation, like one that occurs on
touchscreens since Windows 7.
But after the menu is open, the user would probably expect to be able to
drag the finger to a menu item and release, to select the menu item. For
such a purpose, the existing gesture policies weren't very useful: each
of them resets the timeHeld property if the user drags beyond the drag
threshold; so if the user expects to drag and release over a menu item,
then the timeHeld property cannot drive the menu-opening animation,
because the menu would disappear as soon as the user drags a little.
So it makes more sense to have a gesturePolicy that acts like
WithinBounds, but also applies the same policy to the timeHeld property
and the longPressed signal. We don't care about the drag threshold:
if the user is holding down a finger, it's considered to be a
long-press-in-progress, regardless of how far it has moved since press
(as long as it stays within the parent's bounds).
An example of such a menu is added. The menu must have TapHandler as
its root object, because it reacts to press-and-drag within some larger
item, larger than the menu itself. For example such a menu could be
used in a canvas-like application (drawing, diagramming, dragging things
like photos or file icons, or something like that): dragging items on
the canvas is possible, but long-pressing anywhere will open a context
menu. But in this example so far, only the menu is implemented.
It's a pie menu, because those are particularly touch-friendly; but
perhaps for the mouse, a conventional context menu would be used.
[ChangeLog][QtQuick][Event Handlers] TapHandler now has one more
gesturePolicy value: DragWithinBounds; it is similar to WithinBounds,
except that timeHeld is not reset during dragging, and the longPressed
signal can be emitted regardless of the drag threshold. This is useful
for implementing press-drag-release components such as menus, while
using timeHeld to directly drive an "opening" animation.
Change-Id: I298f8b1ad8f8d7d3c241ef4fdd68e7ec8d8b5bdd
Reviewed-by: Mitch Curtis <mitch.curtis@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>
Shawn Rutledge
Lucie Gérard