qiurui
/
qtdeclarative
mirror of https://github.com/qt/qtdeclarative.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
qtdeclarative/examples/quick/pointerhandlers/tapHandler.qml

239 lines
8.8 KiB
QML
Raw Normal View History

Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
/****************************************************************************
**
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
** Copyright (C) 2021 The Qt Company Ltd.
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
** Contact: https://www.qt.io/licensing/
**
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
** This file is part of the examples of the Qt Toolkit.
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
**
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
** $QT_BEGIN_LICENSE:BSD$
Fix outdated BSD license header Change-Id: Ib1fe267c23ea9fce9bcc0a91ed61081260338460 Reviewed-by: Liang Qi <liang.qi@qt.io>
2017-11-15 15:29:18 +00:00
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and The Qt Company. For licensing terms
** and conditions see https://www.qt.io/terms-conditions. For further
** information use the contact form at https://www.qt.io/contact-us.
**
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
** BSD License Usage
** Alternatively, you may use this file under the terms of the BSD license
** as follows:
**
** "Redistribution and use in source and binary forms, with or without
** modification, are permitted provided that the following conditions are
** met:
** * Redistributions of source code must retain the above copyright
** notice, this list of conditions and the following disclaimer.
** * Redistributions in binary form must reproduce the above copyright
** notice, this list of conditions and the following disclaimer in
** the documentation and/or other materials provided with the
** distribution.
** * Neither the name of The Qt Company Ltd nor the names of its
** contributors may be used to endorse or promote products derived
** from this software without specific prior written permission.
**
**
** THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
** "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
** LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
** A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
** OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
** SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
** LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
** DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
** THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
** (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
** OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE."
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
**
** $QT_END_LICENSE$
**
****************************************************************************/
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
import QtQuick
Add TapHandler.gesturePolicy: DragWithinBounds enum value; examples 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>
2021-10-07 20:27:32 +00:00
import QtQuick.Layouts
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
import "components"
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
Item {
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
width: 800
height: 480
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
Rectangle {
id: rect
Add TapHandler.gesturePolicy: DragWithinBounds enum value; examples 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>
2021-10-07 20:27:32 +00:00
anchors.fill: parent; anchors.margins: 40; anchors.topMargin: 60
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
border.width: 3; border.color: "transparent"
rename TapHandler.isPressed property to pressed 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>
2017-08-28 14:23:20 +00:00
color: handler.pressed ? "lightsteelblue" : "darkgrey"
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
TapHandler {
id: handler
acceptedButtons: (leftAllowedCB.checked ? Qt.LeftButton : Qt.NoButton) |
(middleAllowedCB.checked ? Qt.MiddleButton : Qt.NoButton) |
(rightAllowedCB.checked ? Qt.RightButton : Qt.NoButton)
TapHandler: add gesturePolicy 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>
2016-10-18 16:45:49 +00:00
gesturePolicy: (policyDragThresholdCB.checked ? TapHandler.DragThreshold :
policyWithinBoundsCB.checked ? TapHandler.WithinBounds :
Add TapHandler.gesturePolicy: DragWithinBounds enum value; examples 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>
2021-10-07 20:27:32 +00:00
policyDragWithinBoundsCB.checked ? TapHandler.DragWithinBounds :
TapHandler: add gesturePolicy 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>
2016-10-18 16:45:49 +00:00
TapHandler.ReleaseWithinBounds)
Move properties into grouped "point" property Change-Id: I80000110a2e0ca69210322a0fcc587d86158358e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-02-24 15:42:47 +00:00
Add TapHandler.gesturePolicy: DragWithinBounds enum value; examples 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>
2021-10-07 20:27:32 +00:00
onCanceled: function(point) {
Move properties into grouped "point" property Change-Id: I80000110a2e0ca69210322a0fcc587d86158358e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-02-24 15:42:47 +00:00
console.log("canceled @ " + point.position)
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
borderBlink.blinkColor = "red"
borderBlink.start()
}
Add button argument to the TapHandler.[single|double|]tapped signals It would be better to emit the whole pointer event (by pointer because it's non-copyable, or make it copyable and emit by value), but we can't. So we just add the button being tapped; more information is available from the eventpoint argument and TapHandler's point property. To avoid name clashes with anything that's already called "button" in anyone's QML (which is quite likely, actually), the new signal argument is unnamed, so that users will be required to write a function signature that gives it a name rather than relying on context injection. [ChangeLog][QtQuick][Event Handlers] TapHandler's tapped(), singleTapped() and doubleTapped() signals now have two arguments: the QEventPoint instance, and the button being tapped. If you need it, you should write an explicit function for the signal handler: onTapped: function(point, button) { ... } or onDoubleTapped: (point, button)=> ... Fixes: QTBUG-91350 Task-number: QTBUG-64847 Pick-to: 6.2 6.2.0 Change-Id: I6d25300cbfceb56f27452eac4b29b66bd1b2a41a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-09-07 14:54:44 +00:00
onTapped: function(point, button) {
console.log("tapped button " + button + " @ " + point.scenePosition +
" on device '" + point.device.name + "' with modifiers " + handler.point.modifiers +
" " + (tapCount > 1 ? (tapCount + " times") : "for the first time"))
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
if (tapCount > 1) {
tapCountLabel.text = tapCount
flashAnimation.start()
} else {
Add button argument to the TapHandler.[single|double|]tapped signals It would be better to emit the whole pointer event (by pointer because it's non-copyable, or make it copyable and emit by value), but we can't. So we just add the button being tapped; more information is available from the eventpoint argument and TapHandler's point property. To avoid name clashes with anything that's already called "button" in anyone's QML (which is quite likely, actually), the new signal argument is unnamed, so that users will be required to write a function signature that gives it a name rather than relying on context injection. [ChangeLog][QtQuick][Event Handlers] TapHandler's tapped(), singleTapped() and doubleTapped() signals now have two arguments: the QEventPoint instance, and the button being tapped. If you need it, you should write an explicit function for the signal handler: onTapped: function(point, button) { ... } or onDoubleTapped: (point, button)=> ... Fixes: QTBUG-91350 Task-number: QTBUG-64847 Pick-to: 6.2 6.2.0 Change-Id: I6d25300cbfceb56f27452eac4b29b66bd1b2a41a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-09-07 14:54:44 +00:00
borderBlink.tapFeedback(button)
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
}
}
TapHandler: add long-press feature Add a longPressed signal, emitted when the point is held long enough. Add the longPressThreshold to control how long that is. Change-Id: I95a65f1e4c62eb41fb9ea02b14bdc3f16aa72ec2 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2016-11-18 14:02:18 +00:00
onLongPressed: longPressFeedback.createObject(rect,
Move properties into grouped "point" property Change-Id: I80000110a2e0ca69210322a0fcc587d86158358e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-02-24 15:42:47 +00:00
{"x": point.position.x, "y": point.position.y,
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
"text": "long press after\n" + handler.timeHeld.toFixed(3) + " sec",
TapHandler: emit eventPoint from the tapped signals Any JS callback using one of these signals probably needs to know which button was tapped. We do not want to require TapHandler.point.pressedButtons to tell a lie (temporarily hold the previous state even though a button was actually released). We could add a releasedButtons property, but it would be a bit weird to have it holding state indefinitely between events. We could add just a button parameter to these signals, which would not be so bad, but emitting the whole eventPoint opens up other possibilities, like doing filtering in JS based on the device. To be able to get the device property of the event in QML, it must not be a const pointer. Q_PROPERTY(const type* ...) is so far unprecedented in Qt Quick; and the device has only const properties anyway. This reverts 8dc02aab72a714b5195ccc641fbfb534c3ae9e98 Task-number: QTBUG-61749 Task-number: QTBUG-64847 Change-Id: I09067498b22cc86e9f68c5ff13d6aa5447faba3d Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-26 06:14:13 +00:00
"color": buttonToBlinkColor(point.pressedButtons)})
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
}
Text {
id: tapCountLabel
anchors.centerIn: parent
font.pixelSize: 72
font.weight: Font.Black
SequentialAnimation {
id: flashAnimation
PropertyAction { target: tapCountLabel; property: "visible"; value: true }
PropertyAction { target: tapCountLabel; property: "opacity"; value: 1.0 }
PropertyAction { target: tapCountLabel; property: "scale"; value: 1.0 }
ParallelAnimation {
NumberAnimation {
target: tapCountLabel
property: "opacity"
to: 0
duration: 500
}
NumberAnimation {
target: tapCountLabel
property: "scale"
to: 1.5
duration: 500
}
}
}
}
TapHandler: add timeHeld property It enables long-press gestures to have continuous feedback. Change-Id: Idd0838aff6213ebfc2fce66639bbc932e77208b4 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-08-05 10:45:48 +00:00
Rectangle {
id: expandingCircle
radius: handler.timeHeld * 100
rename TapHandler.isPressed property to pressed 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>
2017-08-28 14:23:20 +00:00
visible: radius > 0 && handler.pressed
TapHandler: add timeHeld property It enables long-press gestures to have continuous feedback. Change-Id: Idd0838aff6213ebfc2fce66639bbc932e77208b4 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-08-05 10:45:48 +00:00
border.width: 3
TapHandler: emit eventPoint from the tapped signals Any JS callback using one of these signals probably needs to know which button was tapped. We do not want to require TapHandler.point.pressedButtons to tell a lie (temporarily hold the previous state even though a button was actually released). We could add a releasedButtons property, but it would be a bit weird to have it holding state indefinitely between events. We could add just a button parameter to these signals, which would not be so bad, but emitting the whole eventPoint opens up other possibilities, like doing filtering in JS based on the device. To be able to get the device property of the event in QML, it must not be a const pointer. Q_PROPERTY(const type* ...) is so far unprecedented in Qt Quick; and the device has only const properties anyway. This reverts 8dc02aab72a714b5195ccc641fbfb534c3ae9e98 Task-number: QTBUG-61749 Task-number: QTBUG-64847 Change-Id: I09067498b22cc86e9f68c5ff13d6aa5447faba3d Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-26 06:14:13 +00:00
border.color: buttonToBlinkColor(handler.point.pressedButtons)
TapHandler: add timeHeld property It enables long-press gestures to have continuous feedback. Change-Id: Idd0838aff6213ebfc2fce66639bbc932e77208b4 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-08-05 10:45:48 +00:00
color: "transparent"
width: radius * 2
height: radius * 2
Move properties into grouped "point" property Change-Id: I80000110a2e0ca69210322a0fcc587d86158358e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2017-02-24 15:42:47 +00:00
x: handler.point.pressPosition.x - radius
y: handler.point.pressPosition.y - radius
TapHandler: add timeHeld property It enables long-press gestures to have continuous feedback. Change-Id: Idd0838aff6213ebfc2fce66639bbc932e77208b4 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-08-05 10:45:48 +00:00
opacity: 0.25
}
TapHandler: add long-press feature Add a longPressed signal, emitted when the point is held long enough. Add the longPressThreshold to control how long that is. Change-Id: I95a65f1e4c62eb41fb9ea02b14bdc3f16aa72ec2 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2016-11-18 14:02:18 +00:00
Component {
id: longPressFeedback
Text { }
}
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
SequentialAnimation {
id: borderBlink
TapHandler: emit eventPoint from the tapped signals Any JS callback using one of these signals probably needs to know which button was tapped. We do not want to require TapHandler.point.pressedButtons to tell a lie (temporarily hold the previous state even though a button was actually released). We could add a releasedButtons property, but it would be a bit weird to have it holding state indefinitely between events. We could add just a button parameter to these signals, which would not be so bad, but emitting the whole eventPoint opens up other possibilities, like doing filtering in JS based on the device. To be able to get the device property of the event in QML, it must not be a const pointer. Q_PROPERTY(const type* ...) is so far unprecedented in Qt Quick; and the device has only const properties anyway. This reverts 8dc02aab72a714b5195ccc641fbfb534c3ae9e98 Task-number: QTBUG-61749 Task-number: QTBUG-64847 Change-Id: I09067498b22cc86e9f68c5ff13d6aa5447faba3d Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-26 06:14:13 +00:00
property color blinkColor: "red"
function tapFeedback(button) {
blinkColor = buttonToBlinkColor(button);
start();
}
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
loops: 3
ScriptAction { script: rect.border.color = borderBlink.blinkColor }
PauseAnimation { duration: 100 }
ScriptAction { script: rect.border.color = "transparent" }
PauseAnimation { duration: 100 }
}
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
Text {
text: "tap, click with different buttons, double-click, long press in this area"
anchors {
bottom: parent.bottom
horizontalCenter: parent.horizontalCenter
margins: 6
}
}
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
}
TapHandler: emit eventPoint from the tapped signals Any JS callback using one of these signals probably needs to know which button was tapped. We do not want to require TapHandler.point.pressedButtons to tell a lie (temporarily hold the previous state even though a button was actually released). We could add a releasedButtons property, but it would be a bit weird to have it holding state indefinitely between events. We could add just a button parameter to these signals, which would not be so bad, but emitting the whole eventPoint opens up other possibilities, like doing filtering in JS based on the device. To be able to get the device property of the event in QML, it must not be a const pointer. Q_PROPERTY(const type* ...) is so far unprecedented in Qt Quick; and the device has only const properties anyway. This reverts 8dc02aab72a714b5195ccc641fbfb534c3ae9e98 Task-number: QTBUG-61749 Task-number: QTBUG-64847 Change-Id: I09067498b22cc86e9f68c5ff13d6aa5447faba3d Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2018-07-26 06:14:13 +00:00
function buttonToBlinkColor(button) {
switch (button) {
case Qt.MiddleButton: return "orange";
case Qt.RightButton: return "magenta";
default: return "green";
}
}
Add TapHandler.gesturePolicy: DragWithinBounds enum value; examples 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>
2021-10-07 20:27:32 +00:00
GridLayout {
columnSpacing: 6; rowSpacing: 6
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
Text {
text: "accepted mouse clicks:"
}
CheckBox {
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
id: leftAllowedCB
checked: true
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
text: "left"
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
}
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
CheckBox {
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
id: middleAllowedCB
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
text: "middle"
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
}
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
CheckBox {
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
id: rightAllowedCB
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
text: "right"
}
Add TapHandler.gesturePolicy: DragWithinBounds enum value; examples 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>
2021-10-07 20:27:32 +00:00
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
Text {
Add TapHandler.gesturePolicy: DragWithinBounds enum value; examples 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>
2021-10-07 20:27:32 +00:00
text: "gesture policy:"
horizontalAlignment: Text.AlignRight
Layout.row: 1
Layout.fillWidth: true
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
}
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
CheckBox {
TapHandler: add gesturePolicy 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>
2016-10-18 16:45:49 +00:00
id: policyDragThresholdCB
text: "drag threshold"
onCheckedChanged: if (checked) {
policyWithinBoundsCB.checked = false;
policyReleaseWithinBoundsCB.checked = false;
Add TapHandler.gesturePolicy: DragWithinBounds enum value; examples 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>
2021-10-07 20:27:32 +00:00
policyDragWithinBoundsCB.checked = false;
TapHandler: add gesturePolicy 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>
2016-10-18 16:45:49 +00:00
}
}
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
CheckBox {
TapHandler: add gesturePolicy 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>
2016-10-18 16:45:49 +00:00
id: policyWithinBoundsCB
text: "within bounds"
onCheckedChanged: if (checked) {
policyDragThresholdCB.checked = false;
policyReleaseWithinBoundsCB.checked = false;
Add TapHandler.gesturePolicy: DragWithinBounds enum value; examples 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>
2021-10-07 20:27:32 +00:00
policyDragWithinBoundsCB.checked = false;
TapHandler: add gesturePolicy 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>
2016-10-18 16:45:49 +00:00
}
}
Move most of the pointer manual tests to a new pointerhandlers example 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>
2021-09-06 19:40:18 +00:00
CheckBox {
TapHandler: add gesturePolicy 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>
2016-10-18 16:45:49 +00:00
id: policyReleaseWithinBoundsCB
checked: true
text: "release within bounds"
onCheckedChanged: if (checked) {
policyDragThresholdCB.checked = false;
policyWithinBoundsCB.checked = false;
Add TapHandler.gesturePolicy: DragWithinBounds enum value; examples 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>
2021-10-07 20:27:32 +00:00
policyDragWithinBoundsCB.checked = false;
}
}
CheckBox {
id: policyDragWithinBoundsCB
text: "drag within bounds"
onCheckedChanged: if (checked) {
policyDragThresholdCB.checked = false;
policyWithinBoundsCB.checked = false;
policyReleaseWithinBoundsCB.checked = false;
TapHandler: add gesturePolicy 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>
2016-10-18 16:45:49 +00:00
}
}
Introduce TapHandler Device-agnostic tap/click detection. Also detect whether the taps or clicks occur close enough together in both time and space to be considered part of a multi-tap gesture. Change-Id: I41a378feea3340b9f0409118273746a289641d6c Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
2015-07-28 13:24:29 +00:00
}
}