qt/qtdeclarative.git/src, branch v6.0.1 Qt Declarative (Quick 2) QQuickWindowIncubationController: Use QPointer to guard QSGRenderLoop reference 2021-01-26T16:37:01+00:00 Mike Achtelik mike.achtelik@gmail.com 2021-01-20T15:14:46+00:00 1fc81ad78c66e76d6c96b43bd67cf969b91d67ca In some cases, when the QGuiApplication is shutting down while there is an active QAnimationDriver and an incubating object, the QQuickWindowIncubationController will try to access an already destroyed QSGRenderLoop. So use a QPointer to guard the QSGRenderLoop access. Fixes: QTBUG-90489 Change-Id: I528e06ff22dfcad804593db6771d9163b21808f4 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> (cherry picked from commit bac93541ba324e75c532c1987e861109e1c5b131) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
In some cases, when the QGuiApplication is shutting down while there
is an active QAnimationDriver and an incubating object, the
QQuickWindowIncubationController will try to access an already
destroyed QSGRenderLoop. So use a QPointer to guard the QSGRenderLoop
access.

Fixes: QTBUG-90489
Change-Id: I528e06ff22dfcad804593db6771d9163b21808f4
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit bac93541ba324e75c532c1987e861109e1c5b131)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
export QAcccessibleQuickItem 2021-01-22T13:25:31+00:00 Jan Arve Sæther jan-arve.saether@qt.io 2021-01-22T10:42:43+00:00 678a223a28994ed45a77a26b008d28832eb11a51 This is needed in order to make controls in qtquickcontrols2 module more accessible. Their accessibility implementation can now inherit from QAcccessibleQuickItem Task-number: QTBUG-75042 Change-Id: I30deba018825937a4ebd757e5250efca87519822 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> (cherry picked from commit 21b975f186e6cec81914b6ee9a6aae5b847069d1) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
This is needed in order to make controls in qtquickcontrols2 module
more accessible. Their accessibility implementation can now inherit
from QAcccessibleQuickItem

Task-number: QTBUG-75042
Change-Id: I30deba018825937a4ebd757e5250efca87519822
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
(cherry picked from commit 21b975f186e6cec81914b6ee9a6aae5b847069d1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QAnimationGroupJob: Don't call virtual functions from dtor 2021-01-22T10:32:57+00:00 Ulf Hermann ulf.hermann@qt.io 2021-01-21T11:06:26+00:00 2dfa486ee951b8fa0a9ea942ebcd6cfca1f3d780 The subclasses are already dead at that point. We don't need to notify them anymore. Rather, refactor the code so that we can clean up QAnimationGroupJob itself without virtual calls. Task-number: QTBUG-90401 Change-Id: I6917bf299ceb1383b9d29687e5bf53ae36803ecf Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> (cherry picked from commit 75437f824d4c3a608af9eb1afddcb4d8c1a25944) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
The subclasses are already dead at that point. We don't need to notify
them anymore. Rather, refactor the code so that we can clean up
QAnimationGroupJob itself without virtual calls.

Task-number: QTBUG-90401
Change-Id: I6917bf299ceb1383b9d29687e5bf53ae36803ecf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
(cherry picked from commit 75437f824d4c3a608af9eb1afddcb4d8c1a25944)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Ensure we cancel touchMouseSynthesis upon receiving touchCancel 2021-01-20T17:50:28+00:00 Richard Moe Gustavsen richard.gustavsen@qt.io 2021-01-20T13:13:44+00:00 8483a1ea8271d45edd89e97ddd37edc73b83ce99 As it stood, we wouldn't cancel touchMouseSynthesis after receiving a touch cancel event. The result would be that the first touch event sent to QQuickWindow thereafter would have touchMouseId set to value different from -1. This again would fool QQuickWindow into believing that the event belonged to a touch event it has synthesized before, and it would as such take a different/wrong path for delivery. This caused text selection to fail on iOS, since a press-and-hold on a line edit from QPA would cancel the touch event and show a magnifier glass. When the user later touched inside the line edit again to move the cursor, this new touch event would not be delivered to the text edit. Fixes: QTBUG-90485 Change-Id: Iad640ae57317ea86ee68ca053654b0b30ade003a Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit a738c3566790c6e9abeea3c4c3dacfceaa82f66a) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
As it stood, we wouldn't cancel touchMouseSynthesis after
receiving a touch cancel event. The result would be that
the first touch event sent to QQuickWindow thereafter would
have touchMouseId set to value different from -1. This
again would fool QQuickWindow into believing that the
event belonged to a touch event it has synthesized
before, and it would as such take a different/wrong path
for delivery.

This caused text selection to fail on iOS, since a
press-and-hold on a line edit from QPA would cancel
the touch event and show a magnifier glass. When the
user later touched inside the line edit again to
move the cursor, this new touch event would not be
delivered to the text edit.

Fixes: QTBUG-90485
Change-Id: Iad640ae57317ea86ee68ca053654b0b30ade003a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit a738c3566790c6e9abeea3c4c3dacfceaa82f66a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Change QQuickShortcut::setSequences to bind to all sequences 2021-01-15T16:21:25+00:00 Andreas Buhr andreas@andreasbuhr.de 2021-01-13T14:29:32+00:00 5a2c0b364a3a5830dd6d5069b5f8d3921aeac73a When binding a Shortcut to a standard key sequence like QKeySequence::FullScreen, it binds only to one key sequence, even though there might be multiple key sequences associated. This patch changes the code to emit a warning in this case and allows to bind to multiple key sequences using 'sequences: [ <key> ]'. Fixes: QTBUG-88682 Change-Id: I88998aa8858d8f2c0c86e46bae94afd7ceb15b66 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 6511b17038627ac30cb6622b13c7d46d9877bac5) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
When binding a Shortcut to a standard key sequence like
QKeySequence::FullScreen, it binds only to one key
sequence, even though there might be multiple key sequences
associated.
This patch changes the code to emit a warning in this case
and allows to bind to multiple key sequences using
'sequences: [ <key> ]'.

Fixes: QTBUG-88682
Change-Id: I88998aa8858d8f2c0c86e46bae94afd7ceb15b66
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 6511b17038627ac30cb6622b13c7d46d9877bac5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Pass QWheelEvent data to QML engine via QQuickWheelEvent pointer 2021-01-15T15:39:43+00:00 Volker Hilsheimer volker.hilsheimer@qt.io 2021-01-14T18:29:45+00:00 76b2d6b7e50ce211641fc6aa9a902719a124e9ca Passing events as objects or references in signal parameters requires copying, and we removed the broken copy semantics from QEvent for Qt 6 as much as possible. QVariant::fromValue still allows creation of a QVariant from a type that doesn't have a (public) copy constructor, which is why this passing of a QWheelEvent through a QVariant to QML went unnoticed. While QWheelEvent is a gadget and thus supposed to be invokable from QML, it's still a QEvent. Most QEvents are not gadgets - like QKeyEvent, QMouseEvent, QTouchEvent. We have QQuick*Event QObject wrappers instead to provide access to the low level event data from QML. So, use a single QQuickWheelEvent object instead to pass the data to QML, that class is designed for exactly that prupose. We need to copy the data anyway, and since we don't need to create/destroy the wrapper object for each event, this has no practical overhead. Extend the QQuickWheelEvent to provide access to the phase information of QWheelEvent as well, and simplify the reset() method. Note: making the QQuickWheelEvent store the QWheelEvent directly would allow passing calls to setAccepted through to the QWheelEvent. That is left for a future cleanup, and another reason for not passing events around as copies. Fixes: QTBUG-89594 Change-Id: Id86a9b30c5a8c7c50091e464e368568a7f5ca2ea Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit 2b15a1fbe2f26a090f79ab5aa238f375bc67fda3) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
Passing events as objects or references in signal parameters requires
copying, and we removed the broken copy semantics from QEvent for Qt 6
as much as possible.

QVariant::fromValue still allows creation of a QVariant from a type
that doesn't have a (public) copy constructor, which is why this
passing of a QWheelEvent through a QVariant to QML went unnoticed.

While QWheelEvent is a gadget and thus supposed to be invokable from
QML, it's still a QEvent. Most QEvents are not gadgets - like QKeyEvent,
QMouseEvent, QTouchEvent. We have QQuick*Event QObject wrappers instead
to provide access to the low level event data from QML.

So, use a single QQuickWheelEvent object instead to pass the data to
QML, that class is designed for exactly that prupose. We need to copy
the data anyway, and since we don't need to create/destroy the wrapper
object for each event, this has no practical overhead.

Extend the QQuickWheelEvent to provide access to the phase information
of QWheelEvent as well, and simplify the reset() method.

Note: making the QQuickWheelEvent store the QWheelEvent directly would
allow passing calls to setAccepted through to the QWheelEvent. That
is left for a future cleanup, and another reason for not passing events
around as copies.

Fixes: QTBUG-89594
Change-Id: Id86a9b30c5a8c7c50091e464e368568a7f5ca2ea
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit 2b15a1fbe2f26a090f79ab5aa238f375bc67fda3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QQmlComponent: Avoid crash when setting initial properties in JS module 2021-01-15T13:10:22+00:00 Fabian Kosmale fabian.kosmale@qt.io 2021-01-14T10:42:20+00:00 ae8fb3800ac880bfa9805f9163709d96b66b7788 In a JS module, we lack a qml context. Thus, we have to check whether qmlContext is null. In that case we use the engine's scriptContext('s ExecutionContext) instead. Fixes: QTBUG-90245 Change-Id: I337e9c7cade472f52fc81c93d1152ff59f8018a5 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit e68b498424f63c1cb6151e4fc6bbc50bac584909) 
In a JS module, we lack a qml context. Thus, we have to check whether
qmlContext is null. In that case we use the engine's scriptContext('s
ExecutionContext) instead.

Fixes: QTBUG-90245
Change-Id: I337e9c7cade472f52fc81c93d1152ff59f8018a5
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit e68b498424f63c1cb6151e4fc6bbc50bac584909)
QuickLayouts: fix crash when layout width depends on parent width 2021-01-15T09:46:10+00:00 Ivan Solovev ivan.solovev@qt.io 2021-01-11T13:44:14+00:00 0b5ae19f733c7d59e6138c677fe432a0e6f25938 Some tricky cases of setting layout width based on parent layout width were leading to infinite recursive loop of layout size calculation (see the attached example in the related Jira task). Initially the QQuickGridLayoutBase::rearrange() method already had a recurse check, but it seemed to happen too late, so that the recursive calls kept happening from the ensureLayoutItemsUpdated() calls. This commit moves the recursion check up, so that it's actually executed before we have a chance to get to the next level of recursion. Fixes: QTBUG-87253 Change-Id: I473ee219e7b5b13547e33ebbd3a6d884de2c7d45 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> (cherry picked from commit 4f8041b01445fd4eec0beb133719645d00d0b2ac) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
Some tricky cases of setting layout width based on parent layout width
were leading to infinite recursive loop of layout size calculation
(see the attached example in the related Jira task).
Initially the QQuickGridLayoutBase::rearrange() method already had
a recurse check, but it seemed to happen too late, so that the
recursive calls kept happening from the ensureLayoutItemsUpdated()
calls.
This commit moves the recursion check up, so that it's actually
executed before we have a chance to get to the next level of recursion.

Fixes: QTBUG-87253
Change-Id: I473ee219e7b5b13547e33ebbd3a6d884de2c7d45
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
(cherry picked from commit 4f8041b01445fd4eec0beb133719645d00d0b2ac)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Flickable: ignore trackpad events with px deltas in disallowed direction 2021-01-15T09:46:09+00:00 Shawn Rutledge shawn.rutledge@qt.io 2021-01-14T17:27:14+00:00 0c3866a5ba406fe7d04ec19cbf8378e9b0150fb0 If Flickable.flickDirection == HorizontalFlick, then if the accumulated QWheelEvent::pixelDelta()'s abs(dx) > 2 * abs(dy), clearly the user is trying to scroll horizontally; otherwise, don't accept the event. That way the event is allowed to propagate to a parent Flickable that does allow flicking vertically. Likewise if the nesting is the other way around, only allow the inner vertical Flickable to accept if the flicking is actually vertical. Fixes: QTBUG-57245 Fixes: QTBUG-80236 Change-Id: Ieb0bf9310a67210ce7e9fe7a80c88baef2cc7ede Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit dccd8f0b5ca8f6faefb49718e33f9090243f3202) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
If Flickable.flickDirection == HorizontalFlick, then if the accumulated
QWheelEvent::pixelDelta()'s abs(dx) > 2 * abs(dy), clearly the user is
trying to scroll horizontally; otherwise, don't accept the event.
That way the event is allowed to propagate to a parent Flickable that
does allow flicking vertically.  Likewise if the nesting is the other
way around, only allow the inner vertical Flickable to accept if the
flicking is actually vertical.

Fixes: QTBUG-57245
Fixes: QTBUG-80236
Change-Id: Ieb0bf9310a67210ce7e9fe7a80c88baef2cc7ede
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit dccd8f0b5ca8f6faefb49718e33f9090243f3202)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Fix Text with ElideRight not being rendered when width goes from 0 to >0 2021-01-14T12:07:35+00:00 Fabian Kosmale fabian.kosmale@qt.io 2021-01-14T08:21:14+00:00 2fee8f1f310406af41fd104892be012d4e633b94 QQuickText attempts to reduce relayouting. However, it was a bit to aggressive in doing that. If only the width changed in a geometrychange, it would not relayout if widthMaximum was true. However, if the width goes from 0 to greater than 0, the value of widthMaximum should have actually been false (but we would only notice this after relayouting). Thus, don't skip relayouting in that case. Amends 56ade46b4234bb828b8e4f9a6bf83b5687bd122e, which fixed the same issue, but for height. Fixes: QTBUG-83408 Fixes: QTBUG-33608 Change-Id: I14b610c703eb0496c71de7b12ad9fcf16842af64 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io> (cherry picked from commit 127c79fb7fda16b9a48ce8c425d1700d1aa7502d) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
QQuickText attempts to reduce relayouting. However, it was a bit to
aggressive in doing that. If only the width changed in a geometrychange,
it would not relayout if widthMaximum was true. However, if the width
goes from 0 to greater than 0, the value of widthMaximum should have
actually been false (but we would only notice this after relayouting).
Thus, don't skip relayouting in that case.
Amends 56ade46b4234bb828b8e4f9a6bf83b5687bd122e, which fixed the same
issue, but for height.

Fixes: QTBUG-83408
Fixes: QTBUG-33608
Change-Id: I14b610c703eb0496c71de7b12ad9fcf16842af64
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
(cherry picked from commit 127c79fb7fda16b9a48ce8c425d1700d1aa7502d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>