qt/qtdeclarative.git/tests, branch 6.6.2 Qt Declarative (Quick 2) Fix polish issue in quick text edit 2024-01-22T16:01:03+00:00 Santhosh Kumar santhosh.kumar.selvaraj@qt.io 2023-11-09T13:05:22+00:00 4cf08f0757ad3e651bb090c6e449ca00b242cb93 The text edit didn't polish even after there is change in position offset, leading to alignment issues. During geometry change, the QQuickTextEdit calculates implicit size and base position offset, and then further requests a polish immediately afterwards. This sequence of update happens only if we have valid width or height set for text edit control. But in case we set width or height to undefined, there is a chance that this update would be missed. This patch removes the checking of widthValid() in QQuickTextEdit::geometryChange(), to allow those updates. The validation of width or height is already handled internally within updateSize(), so it shouldn't create an issue; and we still try to avoid emitting cursorRectangleChanged() too often. Amends 1770fa632facf2f1e4bb05e7689efc939d46cfef Task-number: QTBUG-117667 Task-number: QTBUG-25489 Pick-to: 6.5 Change-Id: Ia20cd06e78842f5edb0c395d6322a660f86f6b5e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit d84c1304112d2198a12e647fd44f57ee0e8dc437) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 3bff953242758365d81e278a6ee0f95f2deb6f1d) Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> 
The text edit didn't polish even after there is change in position
offset, leading to alignment issues.

During geometry change, the QQuickTextEdit calculates implicit size
and base position offset, and then further requests a polish
immediately afterwards. This sequence of update happens only if we have
valid width or height set for text edit control. But in case we set
width or height to undefined, there is a chance that this update
would be missed.

This patch removes the checking of widthValid() in
QQuickTextEdit::geometryChange(), to allow those updates.
The validation of width or height is already handled internally
within updateSize(), so it shouldn't create an issue; and we still
try to avoid emitting cursorRectangleChanged() too often.

Amends 1770fa632facf2f1e4bb05e7689efc939d46cfef

Task-number: QTBUG-117667
Task-number: QTBUG-25489
Pick-to: 6.5
Change-Id: Ia20cd06e78842f5edb0c395d6322a660f86f6b5e
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit d84c1304112d2198a12e647fd44f57ee0e8dc437)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 3bff953242758365d81e278a6ee0f95f2deb6f1d)
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
QQuickWidget: accept touchpoint even if it has a passive grab 2024-01-22T13:15:46+00:00 Shawn Rutledge shawn.rutledge@qt.io 2024-01-04T07:07:05+00:00 0c5a04ee788dc480a1ebb930761dd2ba0e082f05 In the test case from QTBUG-113558, a QQuickWidget's only event-handling object is a TapHandler with its default gesturePolicy, so that on touch press, it gets pressed; but it was missing the touch release and getting stuck in pressed state. As explained in dc8f44b14501ecd4acc196f5138aeff3f7502d0a, widgets don't care about (exclusive or passive) grabbers, and rely on points being accepted to make the widget that received the TouchBegin an implicit grabber. If the only thing that happened in the Qt Quick scene in the QQuickWidget is that the touchpoint got a passive grab, it's still a kind of interaction, and we want to ensure that the TapHandler will see the release too, to avoid getting stuck. (This means that passive grabs are not passive from the perspective of widget event delivery: the TapHandler ends up excluding delivery of the touchpoint to other widgets, even though it didn't mean to. But hopefully nobody expects cooperation with touch-handling widgets underneath the Quick scene.) Fixes: QTBUG-113558 Pick-to: 6.5 Change-Id: Ided6247b43a2405dbfdf9d195bb45ceae4cf58fd Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit 59b0b59090e2ff3f04bd15120720ee6a5b0c3f4b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 9f85654f7d4613ad184ffba950e53a82e61e9cc9) Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> 
In the test case from QTBUG-113558, a QQuickWidget's only event-handling
object is a TapHandler with its default gesturePolicy, so that on touch
press, it gets pressed; but it was missing the touch release and getting
stuck in pressed state.

As explained in dc8f44b14501ecd4acc196f5138aeff3f7502d0a, widgets don't
care about (exclusive or passive) grabbers, and rely on points being
accepted to make the widget that received the TouchBegin an implicit
grabber. If the only thing that happened in the Qt Quick scene in the
QQuickWidget is that the touchpoint got a passive grab, it's still a
kind of interaction, and we want to ensure that the TapHandler will see
the release too, to avoid getting stuck. (This means that passive grabs
are not passive from the perspective of widget event delivery: the
TapHandler ends up excluding delivery of the touchpoint to other
widgets, even though it didn't mean to. But hopefully nobody expects
cooperation with touch-handling widgets underneath the Quick scene.)

Fixes: QTBUG-113558
Pick-to: 6.5
Change-Id: Ided6247b43a2405dbfdf9d195bb45ceae4cf58fd
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 59b0b59090e2ff3f04bd15120720ee6a5b0c3f4b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 9f85654f7d4613ad184ffba950e53a82e61e9cc9)
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Doc & Test: fix syntax of QSettings sub-groups 2024-01-22T08:47:14+00:00 Thiago Macieira thiago.macieira@intel.com 2024-01-18T16:38:35+00:00 9452e8d7dbb019aed1970795e46d1476833e89d4 These examples and .conf files were using two different syntax to create a subgroup. QSettings may not support one of them and is misbehaving. So let's use one syntax only and the one that it produces when writing the output. This code: s.beginGroup(u"Material"); s.beginGroup(u"Font"); s.setValue("Family", "Open Sans"); s.setValue("PixelSize", 20); Produces: [Material] Font\Family=Open Sans Font\PixelSize=20 Fixes: QTBUG-121035 Change-Id: I76ffba14ece04f24b43efffd17ab7ea941910c19 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> (cherry picked from commit e8e818df993113f7c330f8215dccc24c2790f7c5) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 450fdee836866cfc8f62f1bc829f27223946f1da) Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> 
These examples and .conf files were using two different syntax to create
a subgroup. QSettings may not support one of them and is misbehaving. So
let's use one syntax only and the one that it produces when writing the
output.

This code:

    s.beginGroup(u"Material");
    s.beginGroup(u"Font");
    s.setValue("Family", "Open Sans");
    s.setValue("PixelSize", 20);

Produces:

 [Material]
 Font\Family=Open Sans
 Font\PixelSize=20

Fixes: QTBUG-121035
Change-Id: I76ffba14ece04f24b43efffd17ab7ea941910c19
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
(cherry picked from commit e8e818df993113f7c330f8215dccc24c2790f7c5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 450fdee836866cfc8f62f1bc829f27223946f1da)
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
AnimatedImage: avoid loading the same web source in parallel 2024-01-18T22:18:44+00:00 Vladimir Belyavsky belyavskyv@gmail.com 2024-01-05T17:03:46+00:00 4b4af2a02cd85b2e4acf5940b256ff84817edb56 QQuickAnimatedImage::load() is an overloaded method that is called implicitly from QQuickImage/QQuickImageBase whenever an user changes basic properties such as fillMode, mipmap, sourceSize, etc. In the case of a web source, this can cause a real problem with loading failure. For example, when the user changes `fillMode` immediately after setting the `source` property, like: anim.source = <some web image> anim.fillMode = Image.PreserveAspectFit Currently the code above lead to the error "QML AnimatedImage: Error Reading Animated Image File". This happens because QQAI::load() initiates a new network request at the same time that one is already in progress. And when the first reply finishes, we try to read data from the new reply that is not ready yet. To fix this, we can simply ignore and do nothing on QQAI::load() if there is already active network request (i.e. d->reply is not nullptr). This has no effect on the actual source change, since we explicitly remove and nullify the active reply in QQAI::setSource(). By this change we also fix potential memory leak, because the old reply was previously not destroyed properly in QQuickAnimatedImage::load(). Fixes: QTBUG-120555 Pick-to: 6.5 Change-Id: I28f964b51c059855c04a4c80bdce127b3e9974a7 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> (cherry picked from commit fec4ac12e7a60dbd83a2b9c8bb75ad0f88d13a6a) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit a9b0aec18ca5d22537d350fafd795ae8d30d4053) 
QQuickAnimatedImage::load() is an overloaded method that is called implicitly from QQuickImage/QQuickImageBase whenever an user changes basic properties such as fillMode, mipmap, sourceSize, etc.

In the case of a web source, this can cause a real problem with
loading failure. For example, when the user changes `fillMode`
immediately after setting the `source` property, like:

 anim.source = <some web image>
 anim.fillMode = Image.PreserveAspectFit

Currently the code above lead to the error "QML AnimatedImage: Error
Reading Animated Image File". This happens because QQAI::load()
initiates a new network request at the same time that one is already
in progress. And when the first reply finishes, we try to read data from the new reply that is not ready yet.

To fix this, we can simply ignore and do nothing on QQAI::load() if there is already active network request (i.e. d->reply is not
nullptr). This has no effect on the actual source change, since we explicitly remove and nullify the active reply in QQAI::setSource().

By this change we also fix potential memory leak, because the old reply
was previously not destroyed properly in QQuickAnimatedImage::load().

Fixes: QTBUG-120555
Pick-to: 6.5
Change-Id: I28f964b51c059855c04a4c80bdce127b3e9974a7
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
(cherry picked from commit fec4ac12e7a60dbd83a2b9c8bb75ad0f88d13a6a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit a9b0aec18ca5d22537d350fafd795ae8d30d4053)
TableView: don't clear existing selection 2024-01-18T20:55:21+00:00 Richard Moe Gustavsen richard.gustavsen@qt.io 2024-01-08T15:27:53+00:00 77a448c87f175aeac63ccf813599ca035220ce40 If TableView.selectionMode is ExtendedSelection, and the user starts a second selection (by pressing ControlModifier while dragging), the second selection can end up clearing the first if they temporarily overlap. This change will make sure that we save the current selection when a new extended selection starts, to ensure that a cell will stay selected if either the first or the second selection selects it. Fixes: QTBUG-121132 Change-Id: I7bd6eeb4b0cc2372aa683c3c71d8e1b25c5ef17e Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io> (cherry picked from commit 6eb26fe88648265ff4f7f1508280a24bb2cb900d) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit ac4ff59e7be0d80ae5f278491207c5776a080a50) 
If TableView.selectionMode is ExtendedSelection, and the
user starts a second selection (by pressing ControlModifier
while dragging), the second selection can end up clearing
the first if they temporarily overlap.

This change will make sure that we save the current selection
when a new extended selection starts, to ensure that a cell will
stay selected if either the first or the second selection selects
it.

Fixes: QTBUG-121132
Change-Id: I7bd6eeb4b0cc2372aa683c3c71d8e1b25c5ef17e
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
(cherry picked from commit 6eb26fe88648265ff4f7f1508280a24bb2cb900d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit ac4ff59e7be0d80ae5f278491207c5776a080a50)
QtQml: Do not call signal handlers on half-deleted objects 2024-01-18T13:49:11+00:00 Ulf Hermann ulf.hermann@qt.io 2024-01-17T08:01:20+00:00 c24716c7fe465b6a8394211e90e95fb34ef5f990 Fixes: QTBUG-121022 Change-Id: Icdefd6bef4906700d88eca47c09d0abe54f1eec9 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> (cherry picked from commit 9d8e78a2f2661d8a1f2909bfe8a20e15f833af2e) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 5d53ea98449597dbbad38752b4aac80e0aedb341) 
Fixes: QTBUG-121022
Change-Id: Icdefd6bef4906700d88eca47c09d0abe54f1eec9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
(cherry picked from commit 9d8e78a2f2661d8a1f2909bfe8a20e15f833af2e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 5d53ea98449597dbbad38752b4aac80e0aedb341)
qmlformat: Fix object declaration indentation in arrays 2024-01-17T13:44:53+00:00 Joshua Goins joshua.goins@kdab.com 2023-09-13T20:32:46+00:00 dd6346e0f8ba8a1b6672ec3f398cbac013365857 Object declarations inside of array patterns did not insert newlines correctly. This fixes those while not touching other types of array initializations (such as numeric literals) and the one of test data. When extra commas are added to the end of arrays, they are now kept on the correct line as well. Pick-to: 6.5 Change-Id: I8fe67ef066b84f56237449c7695990daa915b4b6 Reviewed-by: Sami Shalayel <sami.shalayel@qt.io> (cherry picked from commit 295a1ce389cda8f360835c89d9a3b32cbcba7eb6) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 2b1bcfd3b6b2bdcd387e3dc645f35afa9672404b) 
Object declarations inside of array patterns did not insert newlines
correctly. This fixes those while not touching other types of array
initializations (such as numeric literals) and the one of test data.

When extra commas are added to the end of arrays, they are now kept on the
correct line as well.

Pick-to: 6.5
Change-Id: I8fe67ef066b84f56237449c7695990daa915b4b6
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
(cherry picked from commit 295a1ce389cda8f360835c89d9a3b32cbcba7eb6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 2b1bcfd3b6b2bdcd387e3dc645f35afa9672404b)
Dialogs: Defer automatic window resolving until dialog is opened 2024-01-17T09:12:18+00:00 Oliver Eftevaag oliver.eftevaag@qt.io 2022-09-15T17:18:09+00:00 4369353527abd987a788943d52104de06c19f2db The qml tool, as well as the QQuickView class are creating their own window outside of the root qml file that is passed to them. This caused an issue where no dialog were able to find a window when componentComplete() was first called, which would make them return early in the QPlatformDialogHelper::show() re-implementations, and thus never show the dialogs when open() was called. This patch solves the issue by waiting until open() is called, before trying to find a window in any of the parent items. Since Window always has a contentItem, it was also possible to simplify the logic that searches for a window, by only trying to cast the parent to QQuickItem*. Another issue that came up, was the fact that dialogs with visible set to true, aka: FileDialog { visible: true } Should open as soon as possible upon its creation. To get around this, open() is called during componentComplete() if a window can be found during this time. Otherwise, the call to open() is deferred until the nearest parent item emits the windowChanged() signal. Note that calling setParentWindow() will now take priority over the implicit window search, unless the argument for setParentWindow is null. Meaning that moving a dialog to a different window, by modifying parents, will not happen for dialogs that are explicitly binding a value to parentWindow. Fixes: QTBUG-106598 Pick-to: 6.5 Change-Id: Idd7c0ecdeea6cbf26e8d41168788563ee9794118 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> (cherry picked from commit f233a5ff9d04daf3ba792cc196da7e5f190b415c) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit ba596daec67fb41d87d6c4a0b31f215fc0a1359d) 
The qml tool, as well as the QQuickView class are creating their own
window outside of the root qml file that is passed to them.

This caused an issue where no dialog were able to find a window when
componentComplete() was first called, which would make them return
early in the QPlatformDialogHelper::show() re-implementations, and
thus never show the dialogs when open() was called.

This patch solves the issue by waiting until open() is called, before
trying to find a window in any of the parent items.

Since Window always has a contentItem, it was also possible to simplify
the logic that searches for a window, by only trying to cast the parent
to QQuickItem*.

Another issue that came up, was the fact that dialogs with visible set
to true, aka:

FileDialog {
    visible: true
}

Should open as soon as possible upon its creation.
To get around this, open() is called during componentComplete() if a
window can be found during this time. Otherwise, the call to open() is
deferred until the nearest parent item emits the windowChanged() signal.

Note that calling setParentWindow() will now take priority over the
implicit window search, unless the argument for setParentWindow is
null. Meaning that moving a dialog to a different window, by modifying
parents, will not happen for dialogs that are explicitly binding a value
to parentWindow.

Fixes: QTBUG-106598
Pick-to: 6.5
Change-Id: Idd7c0ecdeea6cbf26e8d41168788563ee9794118
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit f233a5ff9d04daf3ba792cc196da7e5f190b415c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit ba596daec67fb41d87d6c4a0b31f215fc0a1359d)
QQuickWidget: Clean up if RHI goes away under our feet 2024-01-16T14:25:26+00:00 Tor Arne Vestbø tor.arne.vestbo@qt.io 2023-12-19T20:52:05+00:00 e34b15f0b7c1d686376af878ee58560cea0c517e The QQuickWidget doesn't normally own the RHI; the QWidgetRepaintManager does, via QBackingStoreRhiSupport. If the top level widget is destroyed, so is its QBackingStore, and the corresponding RHI. But the QQuickWidget may outlive its top level parent, in which case it needs to update its cached reference to the RHI, and do proper cleanup before it goes away. QRhiWidget already does the same thing, for the same use-case. This was observed when recreating the top level QWidget via destroy/create as part of the RHI widget compositor logic. Fixes: QTBUG-119760 Pick-to: 6.5 Change-Id: Ic44449abcfe4271660a3ac4e132d0c4a71a21b65 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit 0d342e83123b27befde95fc35760a358dbff0b16) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit df2314d7082e2da8dc33ab2ab6417e5f618b0515) Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io> 
The QQuickWidget doesn't normally own the RHI; the QWidgetRepaintManager
does, via QBackingStoreRhiSupport. If the top level widget is destroyed,
so is its QBackingStore, and the corresponding RHI. But the QQuickWidget
may outlive its top level parent, in which case it needs to update its
cached reference to the RHI, and do proper cleanup before it goes away.

QRhiWidget already does the same thing, for the same use-case.

This was observed when recreating the top level QWidget via destroy/create
as part of the RHI widget compositor logic.

Fixes: QTBUG-119760
Pick-to: 6.5
Change-Id: Ic44449abcfe4271660a3ac4e132d0c4a71a21b65
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 0d342e83123b27befde95fc35760a358dbff0b16)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit df2314d7082e2da8dc33ab2ab6417e5f618b0515)
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
TableView: start a new selection when using Qt::ShiftModifier (PressAndHold) 2024-01-16T10:05:36+00:00 Richard Moe Gustavsen richard.gustavsen@qt.io 2024-01-09T14:46:05+00:00 a63c691041df948152d330b71012b36d626ed0b8 Follow up on previous patch to qquickselectionrectangle, and implement starting a new selection when using Qt::ShiftModifier also for PressAndHold. This configuration, PressAndHold + holding Shift to start a selection, is normally not used in combination. But at the same time, there seems to be no reason why it should't work either, as using selections handles on desktop is allowed. Task-number: QTBUG-120628 Pick-to: 6.5 Change-Id: I8a7589ffd4d16e339a5654605ee0916d96c8cbf0 Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io> (cherry picked from commit 4335010a80a4b5128d3da66c654a458a3b53f65f) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 43ebd251240b5fb07bacfae73eb47eb5234759c1) 
Follow up on previous patch to qquickselectionrectangle, and
implement starting a new selection when using Qt::ShiftModifier
also for PressAndHold. This configuration, PressAndHold + holding
Shift to start a selection, is normally not used in combination.
But at the same time, there seems to be no reason why it should't
work either, as using selections handles on desktop is allowed.

Task-number: QTBUG-120628
Pick-to: 6.5
Change-Id: I8a7589ffd4d16e339a5654605ee0916d96c8cbf0
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
(cherry picked from commit 4335010a80a4b5128d3da66c654a458a3b53f65f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 43ebd251240b5fb07bacfae73eb47eb5234759c1)