Anything emitting executable code at runtime obviously ought to be under utmost scrutinity, so mark most of the JIT related files as critical. Two of the three headers don't contain any actual logic, they get the (default) significant label. Fixes: QTBUG-138341 Pick-to: 6.8 QUIP: 23 Change-Id: I80a39a0154d176c58dee1d865e33cf32149b3a82 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit a3699e3e5cddb5dfca21179f6bd1bc9d88caee5a) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 1bd6f94bc3547771e3fbec89ae1532c14d3f90c4)
We need to actually defer the code which attempts to detect whether we are linking against QtQuick to the point where we write-out the file, as the user is not unlikely to use target_link_libraries _after_ qt_add_qml_module. Amends 065b784cab3ff8e8a1dd1f5a304c6b8c3f222d79. To test that this works, we run the all_qmllint target of on an example project. We need to add a .qmllint.ini file to let qmllint fail the build if there are any warnings. Pick-to: 6.8 Change-Id: I7e00583b3a5b38549db2be13b1a8817b8489496d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 0051e751c3773f63de5259bf9377cab7c6068422) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit a11ad89a3031bb74a36d0e0b9d96eaff13318890)
When building with c++23, the `= nullptr` assignment to a unique_ptr fully instantiates the underlying type to synthesize the destructor. This means the forward declaration cannot be used. Relying on the default constructor as workaround. Pick-to: 6.8 Change-Id: Iff411ae5ea6fe716dc1e2c2c4dbba9e46918fae5 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 3bf35c1d9e9b11a93236612cd4b93e8a7b6519f1) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 83932d0f5d65a6e785e0899113d3559eb6c33816)
This commit moves the "Building UIs with Qt Quick" tree section to the Qt Quick module as a getting started subtree. Changes: qtquick-debugging.html - moved to concepts/Debugging qtquick-deployment.html - moved to concepts/Deployment qtquick-performance.html - moved to concepts/Performance qml-codingconventions.html - moved to guidelines/Coding Conventions scalability.html - moved to guidelines/Scalability qtquick-qml-runtime.html - moved to the qml module "Use Case" topics moved to Getting Started: Visual Elements In QML -> Visual types Positioners and Layouts In QML -> Positioners and layouts Responding To User Input in QML -> Handling user input Displaying Text In QML -> Displaying text Animations In QML -> Animations Style And Theme Support -> was deleted (it had almost zero useful info) Integrating JavaScript in QML -> Integrating JavaScript in QML Task-number: QTBUG-134130 Change-Id: I14c8e4abadc587fbba788b7ce479c3a8364d0a42 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Kai Köhne <kai.koehne@qt.io> (cherry picked from commit 161464abf696d5f64c1e44c3b49313e84e51e709) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit b3dfbbf7a8470b5c79fe2d7ce19e9c406bdcff14)
We emit all warnings with QQmlJSLogger, so don't use qWarning() for parser warnings. This makes our parser warnings more beautiful because QQmlJSLogger can print the code around the invalid token, for example on unexpected token errors. Also make sure that we use the correct logger to emit the parser warning. Pick-to: 6.8 Fixes: QTBUG-137029 Change-Id: Ibf2a24cd17c20edac3c20dd44185f18e891eab66 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io> (cherry picked from commit f3d5e44df8a11ce0636b949ec4e7a73cd4cfd5f8) (cherry picked from commit 5bd55b5c99d628645f7a9ea1fad007e2b2a79af8)
The renderer may receive multiple beginSync/endSync calls, with new path changes inbetween, before updateNode() is performed to commit the new node data. For a shape in the default non-asynchronous mode, the later sync rounds would not be handled in a timely fashion in such cases. Fixes: QTBUG-133267 Pick-to: 6.8 Change-Id: I65345b50755a2528663a28de3599be0b256a4790 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io> (cherry picked from commit b09b10373678e0345bea57910807f9f8f5fe18e4) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit aaa656e470da840559ddf85b56ac810b2a874d7c)
Currently it is not possible to select QAccessible::StaticText with the common keyboard shortcuts of screen readers on Windows. QWindowsUiaTextProvider uses QAccessibleTextInterface but QAccessibleQuickItem does not provide text in text(QAccessible::Value) because QAccessible::Value is logically only implemented for QAccessible::EditableText. So we need to provide QAccessible::Name in the QAccessibleTextInterface. Fixes: QTBUG-137860 Pick-to: 6.8 Change-Id: If5da452985b838d3b4c1dff2444fdea2618aaaf6 Reviewed-by: Shawn Rutledge 🏖️ <shawn.rutledge@qt.io> (cherry picked from commit 30453147f7770e1fad34735240cbd9283814c683) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 18090a16e3443ab705894240402f47ccc9c9091d)
This fixes an error that recently appeared, where FileDialogDelegateLabel weren't considered a valid type by the engine. This is likely related to how QtQuickDialogs uses file selectors to choose which QML files to use. Pick-to: 6.8 Change-Id: I1de72b63100feabfd080a3dc905ef4e120e733cb Reviewed-by: Jonas Karlsson <jonas.karlsson@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> (cherry picked from commit 87f6e63dfc32e4eac861f3490cb961dfbb028b23) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit affce024c8178e55433aed2bdcdb0acd106a3e80)
The documentation on the MS site does not exist anymore. Pick-to: 6.8 Change-Id: Id8093840ac84c0b8d77305dd7b9db28067c3c575 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit 0e67794e730abdf6a9513631510e1f2e4c930bb9) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 1d81e65dc0bddd3b8a4df8f7fa0749f543b27973)
In the quick material style, the primary color or any other colors within its color system would be considered as custom if the set color is outside the predefined enum colors or provided in other color formats. These colors within the material color system can be set by the user through options such as conf or env. The material toolbar, by default, initialises the background color with the primary color. Thus, it's expected implicitly that the background color should reflect the primary color as set by the user. It's also to be noted that this does not necessarily mean to consider background color as custom (as it hasn't been explicitly overridden by the user). This assumption of custom background color has been corrected as part of patch 76d7080fbefc33988d8517f1a964ebdb5c3b3dd2. The controls (such as Toolbar), when requesting the background color, validate whether it has been explicitly set or not. If set, the same shall be provided; otherwise, it can be colors from the predefined range or the default color. In this case, the background color would not be considered as explicitly set (reflecting the primary color), and thus it falls back to the default color as it's also not within the predefined range in the material style. But it's valid to expect the primary color as set by the user. This patch resolves this issue by having additional validation with the primary color properties when providing the background color. Fixes: QTBUG-138602 Change-Id: I1ef1d1b4cd59ec191d6b3cf2886640c52193248e Reviewed-by: Jarkko Koivikko <jarkko.koivikko@code-q.fi> (cherry picked from commit d542f1a60f7617a3b9a465c18e08c5850d38407e) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 6420f64787d40c7bac55d072e758104889915e79)