| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
It opens instantly with right-click; whereas it animates open with
a finger or stylus, to avoid accidental activation, as before.
Pick-to: 6.5 6.6 6.7
Change-Id: I6f530fb6da67c735fe3aae4545c8040f49e8dc05
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
|
| |
|
|
|
|
|
|
| |
We need antialiasing for those menu sector shapes to look good.
Pick-to: 6.7
Change-Id: I0dac2f5b65bf3e8e62387e5189d147de63ef0d7a
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are getting long in the tooth, but multiflame and corkboards seem
worthwhile to update to use Pointer Handlers (as we could have done
sometime during the last 5 years or so).
The qrc prefix seems to have changed: let's get the qmake build
working again.
The multiflame example is mostly rewritten:
- all in one file, which can run standalone
- only one ParticleSystem instance (which hopefully is more efficient)
- using an inline component
- less boilerplate per component instance (only one property for
ColoredEmitter, which is both its color and its group name)
- less-extreme, more fire-like colors
The version of corkboards in Qt Quick 3D was already updated (and then
removed for unrelated reasons); now we have the fixes from
0227fcdf3ea82efee3005d99fd1019410a7f5789
BearWhack has nice graphics, but doesn't seem like a very nice use of
multi-touch, so it's demoted to the touch manual test for now.
The simple Flickable use cases seem underwhelming nowadays too, and
we have snippets as simple as those.
Replace mentions of touchinteraction for testing with pointerhandlers.
Pick-to: 6.6
Change-Id: I4667e13e961ca6f84d3336505b3c673790babfa5
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
| |
|
|
|
|
|
|
|
|
| |
HoverHandler does not react to button presses. Images to indicate button
presses are loaded but never shown because of this. This patch adds an
additional PointHandler which reacts to button presses.
Pick-to: 6.5
Change-Id: I60c1daef5144d7431605b0dc7dbedc0723a17fe0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
The max property is declared inside the "knob" rectangle.
The id of the rectangle should be used, in order to reference it
correctly.
Pick-to: 6.5
Change-Id: I157ab9c3ba687f6e0998f907f064014d03c5902f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
| |
It looks less tedious. Amends 8503f884bbdb50c4bebc8f8a9fce05275b0612b1
Pick-to: 6.2 6.4 6.5
Change-Id: I85690e6a8ceac4ebec1c00bcbbf6a81108096e6c
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If exclusiveSignals == NotExclusive (the default), behavior remains as
it was: singleTapped() and doubleTapped() are emitted as the taps occur,
so it's not very useful to react on singleTapped() if you mean to
distinguish these two cases.
If exclusiveSignals == SingleTap, the doubleTapped signal will not be
emitted at all, and therefore singleTapped can be emitted immediately
and unambiguously.
If exclusiveSignals == DoubleTap, the singleTapped signal will not be
emitted at all, and therefore doubleTapped can be emitted immediately
and unambiguously.
If exclusiveSignals == SingleTap | DoubleTap, we must wait
qApp->styleHints()->mouseDoubleClickInterval() milliseconds after a tap
is detected before emitting either signal, so that they are distinct and
can be used to drive behavior that should not occur in other cases.
A triple-tap will not trigger either signal.
[ChangeLog][QtQuick][Event Handlers] TapHandler.exclusiveSignals now
lets you make the singleTapped and doubleTapped signals exclusive.
Task-number: QTBUG-65088
Fixes: QTBUG-107264
Change-Id: Ifb2c4b72759246c64b3bfa2f776c28266806b985
Reviewed-by: Fabian Kosmale <fabian.kosmale@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>
|
| |
|
|
|
|
|
|
| |
MouseFeedbackSprite now shows a mouse wheel animating in the same
direction as the physical mouse wheel is being rotated.
Change-Id: I08709ead3b85065723d2320d17d49adb51a00f92
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>
|
| |
|
|
|
|
|
|
| |
Also, prefer the multi-line syntax over ';'-separated bindings for
readability.
Change-Id: I3d6eb854e514ee257ca83773a11e6e9e10770bff
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
| |
Many of these are portable to Qt 5; but we don't need the version
numbers in Qt 6, and the components that use "palette" refer to
Item.palette, which was added in Qt 6.
Pick-to: 6.2
Change-Id: Ic799fba5dd66db51a8808c52dce01d27c6da62bb
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
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>
|
