| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At this time, there are not yet any specialized handlers to
do anything specifically with tablet events; but we demonstrate
how to use HoverHandler to detect the type of stylus in use,
and how to use PointHandler to draw on a Canvas.
Unfortunately, events of types TabletEnterProximity and
TabletLeaveProximity are not delivered to the window, only to
QGuiApplication. So HoverHandler can detect when the stylus is moved
out of its parent Item (as long as it's still hovering over the tablet
surface), but cannot detect when the stylus leaves the tablet completely.
In Qt 5 that would require a custom application subclass
(see qtbase/examples/widgets/widgets/tablet/tabletapplication.cpp).
Fixes: QTBUG-79660
Change-Id: I81fdb99082dc41c0455085e6b6d3952402bf8742
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't want it to hold its position indefinitely after the button is
released. But in practice, reset() gets called again anyway in
QQuickSinglePointHandler::handlePointerEventImpl(), _after_
handleEventPoint(), which means after tapped() is emitted. Having the
point hold its position that much longer is convenient for applications
and more consistent with the state expressed by the release event.
Also amend the documentation.
Partially reverts 17237efaefabe924599abe00e92d8b54032d7915
[ChangeLog][Event Handlers][Important Behavior Changes] TapHandler.point now
holds the release position while the tapped() signal is emitted.
Fixes: QTBUG-76871
Task-number: QTBUG-64847
Change-Id: I621a2eba4507a498788e9384344e8b4b7da32403
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
| |
Change-Id: I738b9da5335afb048d2eda2edf2be5095a91d7e5
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* grabPermissions is a flags property, not bool.
* Add a list of the possible grabPermissions values.
* Fix two other places where \qmlproperty enum was used
instead of enumeration.
* acceptedButtons, acceptedDevices, acceptedModifiers and
acceptedPointerTypes are flags properties, not plain int.
Change-Id: I6f49dcc1e1762e913e4989b208380d64899630a6
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
| |
Ignore buttons which do not fit the acceptedButtons filter, and
do not assume that it's all over when any release happens.
Task-number: QTBUG-66360
Change-Id: I871ea7fdd9b76f06fa0d73382617b287c04d35ab
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- Constructors should take QQuickItem* not QObject* to be symmetric
with the parentItem() accessor (and other code) which assumes its type
- Use header initialization everywhere possible
- Reorder variables to minimize padding (somewhat)
- Remove empty destructor bodies (the compiler can write them)
- Remove override and virtual from destructors in accordance with
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override
Change-Id: I682a53a803d65e29136bfaec3a5b534e975ecf30
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At QtCS 2018 we decided to rename Pointer Handlers to Input Handlers
and include the Keys attached property as part of this set (since we
plan to have attached-property pointer handlers too, eventually).
It's no longer a module, it's included in Qt Quick 2.12. We need to
start promoting Input Handlers and reducing the visibility of legacy
stuff like MouseArea and MultiPointTouchArea (in the hope of being
able to deprecate them eventually).
Task-number: QTBUG-66651
Change-Id: I801351ac2531191cbb1faac9318441c67a109af6
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that QQuickMultiPointHandler::m_currentPoints were only
initialized when the candidate points matched the min and max number of
points.
So if we wanted to do a two-finger pinch it would only initialize them
when *both* fingers were pressed. Due to the checking of point->state() in
QQuickHandlerPoint::reset(const QQuickEventPoint *point) it meant that it
would only initialize the press position correctly for the *last* pressed
point. This was because the first pressed point would at the point when
reset() was called have a point->state() == QQuickEventPoint::Updated, so
it would not initialize the pressPosition nor the scenePressPosition.
Luckilly we can get the scenePressPosition from the QQuickEventPoint, but
the pressPosition we have to explicitly localize.
Change-Id: I493c736814cfbc265ec33e8a72fc4283edbbdc43
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickPointerTouchEvent::reset(QEvent *event) reuses instances of
QQuickEventPoint from one touch event to the next, but it makes no
attempt to match up each instance with the same pointId from the event.
So from the perspective of Handlers, each event can have its
touchpoints in a different order, and therefore it's always wrong to
hold onto any QQuickEventPoint pointer between events. Instead we
use QQuickHandlerPoint for storage: both for exposing to QML, and for
internal storage in handlers that need to remember touchpoint state.
Without this change, any MultiPointHandler could "forget" which
point IDs it had chosen to react to, in any case where the event
contains additional points. It was using a QVector<QQuickEventPoint *>
to remember the chosen points, but each of those instances might be
assigned a different touchpoint during the handling of the next
touch event (and thus its ID would change "underneath").
Perhaps this went unnoticed until now because 1) the only subclass
of MultiPointHandler was PinchHandler, and we didn't often test
use cases with extra touchpoints beyond the ones involved in the pinch
and 2) on Linux/X11 they stayed in the same order in each event.
But as soon as we try to make DragHandler inherit MultiPointHandler,
it becomes clear that it does not succeed in holding on to a particular
touchpoint while dragging multiple DragHandlers with multiple fingers,
without this patch.
Change-Id: If7e0daa9ed77b263efc09f5ea73dfba6a3c8205c
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
Conflicts:
src/plugins/qmltooling/packetprotocol/qpacketprotocol.cpp
src/quick/handlers/qquickhandlerpoint.cpp
src/quick/handlers/qquicksinglepointhandler.cpp
tests/auto/qml/ecmascripttests/test262
Change-Id: I8908ec8c6116ca626fbd269af7625d4c429429ca
|
| |
|
|
|
|
|
|
|
| |
The event includes it; this exposes it to QML, for the benefit of
conditional JS logic in Pointer Handler use cases.
Task-number: QTBUG-68101
Change-Id: I3f04c5db7f5aef461edb6168922b70e3fb3bda37
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of the reasons we were so fond of using SinglePointHandler for the
"simple" handlers like TapHandler and DragHandler is that it has the
point property, which is easy to bind to in QML. But multi-point
handlers tend to use the centroid as the focal point or fulcrum of
the transformation, so exposing the centroid as a QQuickHandlerPoint
gadget rather than just a QPointF has all the same advantages as the
point property in SinglePointHandler, including letting the
QQuickHandlerPoint instance store state between events (press
position, grab position, last known position etc.)
Change-Id: I4a955fa21b54b7ebb50b0ee2c942fb98eeccb560
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
...in anticipation of needing it in QQuickMultiPointHandler.
Change-Id: Id98f2da34ee12b4cea3ba58550b446bfc989da1b
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
