| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
tqtc/lts-6.2-opensource
Conflicts solved in a file:
dependencies.yaml
Change-Id: Ib4083daa41a689b937d2aeb522e93e3aab0be1c4
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Animated gifs were captured with byzanz-record, then converted to webp:
gif2webp -lossy -min_size -q 40 -m 6 -mt -metadata none in.gif -o out.webp
Fixes: QTBUG-96915
Change-Id: Iee2f4ef774de7862d93c7e4cdf7b2b5e0553bec4
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
(cherry picked from commit 024794255d7d1df10fa5239cb70212c9703ff60f)
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Like acceptedButtons, HoverHandler.dragThreshold is irrelevant.
Task-number: QTBUG-95395
Change-Id: I059e99449cff946b2caa945022b1f4bd4d2f845b
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit 17e8e21511ce3f5a2cc764655f12355454ae0522)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |\|
| |
| |
| |
| |
| | |
tqtc/lts-6.2-opensource
Change-Id: Ib72ded968b7ac6b75b499392162e3cf3b761ec48
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
According to the documentation for HoverHandler::enabled, a
disabled hover handler will not accept any mouse events. It
therefore follows naturally that a disabled HoverHandler
should also not affect event propagation elsewhere.
This patch will change the implementation, so that
we don't deliver hover events to HoverHandlers that are disabled.
This also means that disabled HoverHandlers will no longer block
propagation to its siblings.
[ChangeLog][QtQuick][HoverHandler] Disabled hover handlers
will no longer receive hover events, or block siblings from
being hovered.
Fixes: QTBUG-106548
Change-Id: I7f2e459ba39f1e23cdb13bf94f8754e185dcd0c1
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit 205e31df1674da5d9de78c4338d3221309086333)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |\|
| |
| |
| |
| |
| | |
tqtc/lts-6.2-opensource
Change-Id: Ie5a87ae61d8ed0429225353ad46e5232d60f4daa
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Including moc files directly into their classes' TU tends to improve
codegen and enables extended compiler warnings, e.g. about unused
private functions or fields.
Manual conflict resolutions:
- dropped all includes into non-existing files
Task-number: QTBUG-102948
Change-Id: I695daa12613de3bada67eb69a26a8dce07c4b85e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 6a23f186138dff2a7007288a02702bce23d7ca70)
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |/
|
|
|
|
|
|
|
|
|
| |
This reverts commit 74089697cf2a4961fb697100555b17ae2342d734.
Revert of commercial license headers is required for the
Qt 6.2.x opensource releases, Qt 6.2.5 onwards.
Task-number: QTBUG-107760
Change-Id: Id49069cb5e5f261da185fd082dfb71deb259d387
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Some base class snippets use TapHandler, but it's better to show
snippets specifically with HoverHandler. These snippets are also
runnable and thus testable.
Fixes: QTBUG-95395
Task-number: QTBUG-101932
Change-Id: Ibcdc30ff8a785a3651177c79522332cf09c3013c
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
(cherry picked from commit a76ad7ef6a87af074612897ea6df30167ebe698e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updated header.COMM to the files in tqtc-qtdeclarative.
Examples, tests, or documentation files are not updated.
The commercial license header may contain some
additional lines so that its line count equals with
the earlier license header. Reason for this is that
some autotests use hard coded line numbers and a
change in the line count causes failures in tests.
Task-number: QTQAINFRA-4941
Change-Id: I32f554b0a8cb527f74d46f3c02b0e745d9fc5ddf
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a HoverHandler is declared in a Window, the handler's bindings
are evaluated before QQuickItemPrivate::data_append() is called to
add the handler to the window's content item. So we need null pointer
checks again (as we have for a lot of calls to parentItem() already).
And to ensure that the declared cursorShape actually is shown, we need
to check again in componentComplete(). And don't forget to call the
parent class implementation whenever overriding any virtual function.
Fixes: QTBUG-98717
Change-Id: Id0defac7a238df522e8eee69f71e83a3947560af
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 3e95a57dc1fb39b059b52e16fcce7b4262f88b61)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the bug, HoverHandler was getting "hovered" during clicking, even
though it already had the opportunity to be hovered while the mouse
got into its parent's bounds (and at that time, it got un-hovered while
Button was hovered instead). It gets hovered because
QQuickDeliveryAgentPrivate::deliverMatchingPointsToItem() calls
QQuickItemPrivate::handlePointerEvent() on the ListView's contentItem,
because it has a handler. So it seems HoverHandler should not react to
that event, because a button is being pressed.
Fixes: QTBUG-72843
Change-Id: I0bbcd351130a8d16165f04809c039b24b3864bf9
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 8449180c5ebd609b6788680173a79df2f239abb8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickDeliveryAgent will clear the list of passive grabbers
when we deliver:
1. a QPointerEvent::isEndEvent() from deliverPointerEvent()
2. a QEventPoint::Pressed event from deliverPressOrReleaseEvent()
In other words, QQuickDeliveryAgent will clear the list of grabbers
whenever it receives a mouse press or release. This doesn't work
well with hover handlers, which were using passive grabs to
ensure receiving updates: they also lost their grabs on press and
release. This has some implications:
1. the list of hover items (QQuickDeliveryAgentPrivate::hoverItems)
will no longer be in sync with the items we deliver events to.
2. a hover handler stacked underneath another hover handler
will stop working. The reason is that QQuickDeliveryAgent
detects that hoverItems is not empty, and as such, assumes
that all handlers will receive events from their passive grabs.
(which is no longer the case after the clear)
So letting hover handlers rely on passive grabbing currently fails.
It was also confusing that we delivered some of the hover events
from deliverHoverEvent(), and others from passive grabs in
deliverPointerEvent(). In Qt Quick 3D, when the hover is delivered
because of a passive grab, we need to use sceneTransform; but when
picking is done, the transform was already done at the same time.
But hover events that come from flushFrameSynchronousEvents()
always need to go through picking, and that happens frequently,
so it's more consistent if we just rely on it all the time.
In addition, the previous solution was assuming that only one leaf item
would be under the mouse. This fails when you have siblings that overlap
(and each sibling has HoverHandlers).
While we could try to be more careful about when, and which, grabbers
we clear here and there from QQuickDeliveryAgent, it seems better to
dodge the whole passive grabber logic for hover handlers, and instead
send all hover events directly from deliverHoverEvent(). This because
we anyway need to traverse all the items in the application on each
pointer move to check if new items are being hovered. So we might as
well send out hover events in the same go. That way the logic becomes
a bit easier to follow, and don't need to worry about keeping the
hoveredItems list in sync with passive grabbing.
tst_qquickhoverhandler:
hoverHandlerAndUnderlyingMouseArea:
- HoverHandlers have (conceptually) never stopped hover events
from propagating to the parent. Still, this test checks that
a MouseArea underneath a HoverHandler is not hovered. Since
this now actually works, the test is changed.
mouseAreaAndUnderlyingHoverHandler:
- MouseArea now accepts hover events, which will stop propagation.
This is done to preserve the same behavior as before. But this
also means that a MouseArea that has another MouseArea as a direct
child (which was a special case from before) will no longer get hover
events after the child has accepted them. For the same reason, an
item's HoverHandlers will also not get hover events if there is a
child that is accepting them, as in this test case.
Fixes: QTBUG-34882
Fixes: QTBUG-63670
Change-Id: Id38042bcbd1c3ca5403b4b81b875b84196fcfc76
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit bbcc2657fa0dbf715e6db7d675662e4be94a1e04)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mainly it's a matter of removing the assumption that parent() is always
a QQuickItem. But handlers that have a target property do not know how
to manipulate it when it's not an item; so for example you can use
DragHandler's translation property to manipulate the object, but it
doesn't drag a 3D object by default.
Delivery logic for now is implemented in QQuick3DViewport, because it's
intimately tied to picking, and QQuickDeliveryAgent doesn't really know
anything about QQ3D objects, and the conventional delivery to handlers
in Qt Quick depends on QQuickItemPrivate::handlePointerEvent()
which isn't available in that use case.
Hover events are interfering with DragHnadler (wantsPointerEvent()
returns false, therefore the handler gets deactivated right away).
HoverHandler detects hover but does not detect leave, but that's
probably a matter for the delivery logic to fix.
Change-Id: Id0ec385ce8df3a003f72a6666d16632cef72bbd6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| |
|
|
|
|
|
| |
They are moved to QQuickDeliveryAgentPrivate.
Change-Id: I5d6656dd6362dd03f0f4321cff07a8b207fadd39
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
Let HoverHandler listen for HoverLeave events, so that we can explicitly
tell it to leave its hovering state from the outside.
The new function gets used in a follow up patch.
Change-Id: Ieaaeb7dc4e4afc96bb60c7abfd34f2c2c09bef47
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
| |
- Remove links to modules and examples that are not part of Qt 6.
- Remove links to entities marked as \internal
- Add missing enum value and QML property docs where it's trivial
to do so.
Task-number: QTBUG-88156
Change-Id: I10a1c7bcc5fe0e2354ea69eaf24930362edb7415
Reviewed-by: Paul Wicking <paul.wicking@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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
...and generally deal with changes immediately required after adding
QInputDevice and QPointingDevice.
Also fixed a few usages of deprecated accessors that weren't taken
care of in 212c2bffbb041aee0e3c9a7f0551ef151ed2d3ad.
Task-number: QTBUG-46412
Task-number: QTBUG-69433
Task-number: QTBUG-72167
Change-Id: I93a2643162878afa216556f10808fd92e0b20071
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It doesn't make sense to show hover feedback after releasing a
touchpoint just because the core pointer cursor happened to move along
with the touchpoint, so we explicitly set the hovered property to
false when the touchpoint is released. However the next mouse movement
will set it back to true again if the mouse cursor is still inside.
This is especially important for touchscreen-based haptic interfaces:
any hover feedback should be shown when a finger is dragged into an
interface element and hidden again when the finger is released.
Change-Id: Iff7f23f089466cc0da94d2a46690719f6d70cae2
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |\
| |
| |
| | |
Change-Id: I0ae0a162e133cffd8fb1a2c6b70826e50f06facd
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
It was intended to inherit most of the docs from SinglePointHandler; but
the hovered property is unique.
Task-number: QTBUG-68072
Change-Id: I4b49569c9966b9252a61e40e8b07ef98f34849a4
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |\|
| |
| |
| |
| |
| |
| |
| |
| | |
Required a change to a #include; qquicksinglepointhandler.cpp was (at
least on Android) only seeing QQuickSinglePointHandler as a forward
declaration, so dereferencing it was a problem. The header that
defines it does #include the one it replaces here.
Change-Id: I6bc30ff9a91f55350172e4a4bcaaa7f99a2ffb28
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Reverts what's left of e53510944169ac9f6753e0d14e1b24a24ff7bd9a
(amends 73258eca7ab7e3981d9f4aaa5484020cb67854a0):
MultiPointHandler is not only for touch handling anymore.
DragHandler in particular needs to respect the acceptedButtons property.
Fixes: QTBUG-76875
Fixes: QTBUG-76582
Change-Id: I414e785dd09b297c93e5e9f162be23e4a44eca54
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
|
|
|
| |
Change-Id: I19545953bde10d4ccc2f37843dcda2569dc77df4
Reviewed-by: Martin Smith <martin.smith@qt.io>
|
| |
|
|
|
|
|
| |
Task-number: QTBUG-70142
Change-Id: I97fe80e94a553d81695f4516e84ff8ac0d086347
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
| |
After 6008c5ded48b6d03d56bf4c4ab96177fbb185f93,
QQuickPointerHandler::wantsEventPoint() does not check parentContains()
so we have to do it in HoverHandler itself.
Change-Id: I5bdebc251091367dbebfbab1fcb81c0b120d7902
Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
|
|
|
Detect whether the handler's parent contains the mouse, while the
point property tracks the event point (position etc.)
Task-number: QTBUG-68072
Change-Id: Ica99332596eab3e344852a11f1ceb7aaf6348c86
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
