| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Making properties FINAL is an API break not covered by any QUIP rule.
However, this does not apply to the attached and uncreatable types
(either explicitly, or because they are singletons or value types) whose
properties were marked FINAL in the referenced commit, as it is not
possible to derive from them anyway. So those are left with their
properties still marked as final.
This partially reverts commit 351979e05ad2a861fc3e6f8d1de6197a751316a8.
Pick-to: 6.6 6.7
Change-Id: I1ce8c0873c4600ec2aad8e078c379239ad03f74a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
| |
|
|
|
|
| |
Task-number: QTBUG-117983
Change-Id: Ia904c9390efb13b92de2e16fa0690e48394f9bab
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without setting the FINAL flag, properties can be shadowed by users.
In the following example:
Image {
property string source: "Shadowing QQuickImage::source"
}
The source property of QQuickImage, will be shadowed by a new property
with the same name.
This can both cause confusion for non-experienced users, and it causes
issues with qmlsc.
Shadowing a property is usually unwanted. But there are some situations
where it might be intended. The QML Object Attributes doc page
demonstrates that you can override the color property in
QQuickRectangle, for instance.
[ChangeLog][Important Behavior Changes][QtQuick] Most properties for
types in the QtQuick module are now FINAL, meaning that they can no
longer be shadowed by declaring new properties with the same names.
With few exceptions. A warning will be printed out to the console, when
a FINAL property is shadowed. We recommend that users rename those
properties to avoid potential unexpected behavior changes.
Task-number: QTBUG-108739
Pick-to: 6.6
Change-Id: I1070926606f4d88ef7edf088ff80fb3ec82305c8
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The referenced bug report specifically complained about warnings caused
by including qquickpointerhandler_p.h. All of those -Wshorten-64-to-32
warnings come from headers that aren't strictly needed for
qquickpointerhandler_p, though.
So fix the issue by only including what is actually need, which also
slightly improves compile times. This requires adding a few transitive
includes in select places.
As a drive-by, remove the unneeded QML_DECLARE_TYPE.
Fixes: QTBUG-105055
Change-Id: I24d78e7131771a4bbcb402e6838a5a9a11abbbec
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
[ChangeLog][Event Handlers] The parent property of any Pointer Handler
is now settable.
Fixes: QTBUG-84730
Task-number: QTBUG-85926
Task-number: QTBUG-17286
Change-Id: Id738dd783de1acfbef9b5be203025040b0913008
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
This is more robust than just going by the "parent" name.
Task-number: QTBUG-93662
Change-Id: If099733de6ad0f3bb7cb75b8915789f66b554f85
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickWindow owns QQuickRootItem which owns QQuickDeliveryAgent, so
for every window there's an object responsible for event delivery,
while the window itself is mainly responsible for rendering (separation
of concerns). However, QQuickRootItem and QQuickDeliveryAgent can now
be used in cases where the scene doesn't directly belong to a window,
such as when a Qt Quick sub-scene is mapped somewhere into a Qt Quick 3D
scene. In that case, we must remember which delivery agent was in use
at the time when a QEventPoint is grabbed and deliver subsequent updates
via the same DA. There's also a QQuickDeliveryAgent::Transform
abstraction which subscene-management code (such as QQuick3DViewport)
can implement, to provide a formula to map the window's scene
coordinates to subscene coordinates; if defined, it will be used
during delivery of subsequent updates to existing grabbers.
Task-number: QTBUG-84870
Change-Id: I70b433f7ebb05d2e60214ff3192e05da0aa84a42
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QEventPoint does not have an accessor to get the QPointerEvent that it
came from, because that's inconsistent with the idea that QPointerEvent
instances are temporary, stack-allocated and movable (the pointer would
often be wrong or null, therefore could not be relied upon).
So most functions that worked directly with QQuickEventPoint before
(which fortunately are still private API) now need to receive the
QPointerEvent too, which we choose to pass by pointer. QEventPoint is
always passed by reference (const where possible) to be consistent with
functions in QPointerEvent that take QEventPoint by reference.
QEventPoint::velocity() should be always in scene coordinates now, which
saves us the trouble of transforming it to each item's coordinate system
during delivery, but means that it will need to be done in handlers or
applications sometimes. If we were going to transform it, it would be
important to also store the sceneVelocity separately in QEventPoint
so that the transformation could be done repeatedly for different items.
Task-number: QTBUG-72173
Change-Id: I7ee164d2e6893c4e407fb7d579c75aa32843933a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| |
|
|
|
| |
Change-Id: Id72fbe10c16de61bd847773d0055d83cfe03f63c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, QQuickItemPrivate::setHasCursorInChild() was unable to check
the QQuickItemPrivate::hasCursor variable, because the function
argument hasCursor was shadowing that, even though the comment
"nope! sorry, I have a cursor myself" hints that the intention
was to check that. So this change exposed a problem there, and
we have to fix that too, in order to keep the tst_qquickwindow::cursor()
test passing.
[ChangeLog][Event Handlers] Pointer Handlers now have a cursorShape
property to set the cursor when the handler is active and the mouse is
hovering, and restore to the previous cursor when the mouse leaves.
Fixes: QTBUG-68073
Change-Id: Ib5c66bd59c4691c4210ee5465e1c95e7bdcf5ae1
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using this technique we can automatically register all necessary
revisions and minor versions of a type, using the metaobject system.
This greatly reduces the potential for mistakes and resulting
incompatibilities between versions of imports.
We assume that for each type we need to register all revisions of its
super types and its attached type, and that the revisions match. That
is, if you import version X of type A, you will also get version X of
its attached type and of any super types. As we previously didn't take
these dependencies into account when manually registering the types, a
number of extra revisions are now registered for some types.
Potentially, we can now generate the qmltypes files at compile time,
using moc.
Change-Id: I7abb8a5c39f5e63ad1a0cb41a783f2c91909491b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need drag threshold to be adjustable on each handler instance instead
of relying only on the system default drag threshold. For example in
some use cases DragHandler needs to work with a threshold of 0 or 1 to
start dragging as soon as the point is pressed or as soon as the point
is moved, with no "jump", to enable fine adjustment of a value on some
control such as a Slider.
This involves moving the dragOverThreshold() functions that handlers are
using from QQuickWindowPrivate to QQuickPointerHandlerPrivate, so that
they can use the adjustable threshold value.
Task-number: QTBUG-68075
Change-Id: Ie720cbbf9f30abb40d1731d92f8e7f1e6534eeb5
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enum represents a transient state transition, and only sometimes
corresponds to the current grab state of an event point. For example
after exclusive grab has been canceled, the current state is that
there is no exclusive grab: it doesn't make sense to remember that the
way it got there was by cancellation. There was an idea to add a
grabState property, but not all values would be eligible. An
EventPoint can be exclusively grabbed by one item or handler at a
time, and by multiple passive grabbers at the same time, so even a
Q_FLAG would not fully express all possible states. Besides, there is
already an exclusiveGrabber property, and we could add a
passiveGrabbers list property if we had a real need. So adding a
grabState property seems unlikely, and therefore is not a good enough
reason to keep this enum named as GrabState.
Change-Id: Ie37742b4bd431a7e51910d79a7223fba9a6bd848
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's not just useful for PinchHandler: TapHandler has a good use for it
too. But unfortunately if the handler's parent Item has a custom mask,
we don't have a way to augment the mask with a margin; so if margin is
set, we assume the bounds are rectangular.
QQuickMultiPointHandler::eligiblePoints() now calls wantsEventPoint()
rather than bounds-checking the point directly: this adds flexibility,
potentially allowing an override in subclasses, if we need it later.
Task-number: QTBUG-68077
Change-Id: I65c95f00c532044a5862654e58c9c5f8c973df81
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
| |
To make grabChanged signal useful, it's necessary to know whether the
Pointer Handler has acquired or lost the grab. This patch fixes that.
Task-number: QTBUG-68074
Change-Id: I29398d2bb5b27b8541197f23c3043ee86cad7c76
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
| |
We want to be able to call it from the upcoming
QQuickItemPrivate::anyPointerHandlerWants function.
Change-Id: I15ef60303fa56f43e66b16c8dd0f4102070536d0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
| |
Follow the usual pattern in preparation for making this class public.
Change-Id: I8330cdda27e131a5f93723d4cf4c53a9f7630434
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
| |
They are public in QQmlParserStatus but don't need to be public here.
Also de-inline the default implementations, because this class will
be public C++ API eventually.
Change-Id: Ic7dfbec853e3d20f45b361401f710dedb5eae416
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
From now on we prefer nullptr instead of 0 to clarify cases where
we are assigning or testing a pointer rather than a numeric zero.
Also, replaced cases where 0 was passed as Qt::KeyboardModifiers
with Qt::NoModifier (clang-tidy replaced them with nullptr, which
waas wrong, so it was just as well to make the tests more readable
rather than to revert those lines).
Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
|
|
|
| |
componentComplete() is useful to inform the handler that
its parent Item is complete.
Change-Id: Iec0e171d647dad45e0af2e0878f540d6f76f53bf
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
| |
To be overridden in handlers which need to know when this happens,
to avoid connecting to the targetChanged() signal.
Change-Id: I51432b69d05fd541eb62e0cd01f4019e336816ac
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As soon as we enable the concept that PointerHandlers can use passive
grabs to lurk, monitor all movements, and then steal the passive grab,
they can fight over the grab. For example if there are two items with
PinchHandlers, and two or more touches occur within bounds for both,
then each update event can cause the other PinchHandler to steal the
grabs and become active.
So we replace stealing with negotiation: the handler which wants to
take over the grab checks its own flags to see whether that's allowed,
and the handler which is about to lose its grab also has the right
to approve or deny the takeover (just as QQuickItem has had
keepMouseGrab and keepTouchGrab for a long time.) Additionally,
if one handler wants to cancel another handler's grab without
taking over (simply set the grabber to null), it must be approved.
A single-point handler can simply call setExclusiveGrab, with the
expectation that permission may be granted or denied. A multi-point
handler only wants to grab all points if grabbing all of them will
be allowed, otherwise grab none; so it calls canGrab on each point
to check beforehand. Thus, when two handlers are competing for the
same grabs, one or both can be prevented from stealing from each other,
or from Handlers in general, or from Items, or some combination.
Change-Id: I5c733b2b8995ce686da0be42244394eeee82a268
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
| |
Now that onGrabChanged() is unified, we have a means to tell the
handler when it loses its grab due to a touch event being canceled.
Change-Id: Idf3649242233ac7fb8c1fa80ad257ee14b861090
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
| |
Change-Id: I17b3865d70bdc07912d7454b459dea40b9c98df0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
onGrabChanged and handleGrab looked redundant. It was also not clear
how important it is for handlers to react to passive ungrabs, overrides
or cancellations. Rather than debating about when to call one of these
and when not to, let's centralize the responsibility in
QQuickEventPoint (because the grabber pointers are stored there, so
it's the ultimate destination of any grab change), and let's notify
all the relevant handlers about all changes, with enough information
that each handler can decide for itself what's important and what
isn't. But so far most handlers don't need to override this virtual.
The base class QQuickPointerHandler takes care of setting the
active property to false, rejecting the eventpoint, and unsetting
keepMouseGrab and keepTouchGrab whenever grab is lost; and emitting
grabChanged or canceled as appropriate to notify any QML code which
needs to know. Subclasses mainly care about the change of active state:
they must initiate active state themselves, and may react when it
reverts to false.
Change-Id: I6c7f29472d12564d74ae091b0c81fa08fe131ce7
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Whenever the DragHandler gets an exclusive grab, it needs to prevent
a parent Flickable (for example) from taking over that grab. Since
it waits until the drag threshold is exceeded in an allowed dragging
direction, this does not prevent the Flickable from being draggable
in the other direction.
We restore the state of keepTouchGrab and keepMouseGrab when ungrabbing.
Change-Id: Id9d456c99322e0cb6996d1f690b38fcd6becc6f9
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
| |
Change-Id: I45df7abdbd91e068a69101ed27e2ec44272e3899
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
| |
Change-Id: I4a6e3c72d69e893fec2e39f4faab24af6d00c7e0
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
| |
To summarize: A pointer handler always gets its pointer events from its
parent item. It applies its effect (drag, pinch, ...) on the item
referenced to by the target property. By default, target refers to the
parent, but that is not always the case. In addition to this we also
have to handle the case when the target is null
Change-Id: If62108abf0aeb713906bf88472ad9a32a74efff6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
| |
Some handlers will need to react to gaining or losing a grab, in both
C++ and QML.
Change-Id: I25b94800e3eaeabb0782315c679813ec735d4d51
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
and override it in PinchHandler. Many handlers will need to do
something in response to change in active state, so calling a virtual
when the state changes and overriding it in subclasses is more
efficient than for subclasses to connect to the activeChanged signal.
This also helps us control the signal emit order: the subclass can
deal with any consequences (such as changing its own properties) before
activeChanged is emitted.
Change-Id: I6d05643e8facfd1941aa9152de6865932edb1b3a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
The parent is the Item in which the handler is instantiated.
It cannot (so far) be reassigned to a different item, so this is not
the same as QQuickItem's parent property: it's rather a convenience
to get the QObject parent and cast it.
Change-Id: Ib352213589532f45f104c8d83f04fd14107a4a20
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Only one handler can be the grabber at one time, so we need to ensure
that we notify the others when they lose the grab. Also handle this
in QQuickPointerSingleHandler: forget m_currentPointId, so that
wantsPointerEvent will not continue to "want" the same ID.
Also add the canceled(QQuickEventPoint *point) signal, which
is one of the four possible "state signals" (press, update, release,
cancel) but which we didn't commit to adding yet.
Change-Id: I46256acb75ece863d84e812af2d30cb0b12e3c1f
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
|
| |
|
|
|
|
|
|
| |
By default, a handler is active whenever wantsPointerEvent() returns
true, and inactive when it returns false.
Change-Id: I627762ba8f4eed167f675f220ffaed79c93c8448
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There will be an inheritance hierarchy of pointer handlers. The base
class doesn't have enough information to know whether an event should
be accepted or rejected, so it cannot change the state of the event,
so there's no way for a subclass to benefit from the base class's
checking of m_enabled, if it has no way to communicate to the
subclasses. An intermediate class has more information which
contributes to the decision of whether to accept or reject, but still
not enough: the leaf class must make the final decision. So we need a
virtual bool function, at least as an implementation detail, even
though from the perspective of event delivery, there's only one
outcome: the event is accepted, or not. We have eschewed public bool
functions to avoid ambiguity during delivery: there is no return
value to pay attention to, only the accepted state of the event.
Change-Id: Ieaca4968fce0064f80b5460aa4c10b431036e12a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
|
| |
|
|
|
|
|
| |
Most handlers will need to check this.
Change-Id: I44858c0ac4ccb58a9a2de70382e3954af6554ef3
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
| |
This is to compensate for the fact that the EventPoint does not store
the Item-localized position, only scenePos. Either it should store it
or we have to recalculate it in each Handler.
Change-Id: I5b02814d5fd7930bb32b547c1af00808b8e23b80
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
|
|
|
They will be Tech Preview in 5.8, so they shouldn't be available
unless you explicitly import them.
Task-number: QTBUG-54824
Change-Id: I290854a4e2b76e2cdfef5c216c7fdeb47fbcd390
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
|
