qtdeclarative/tests
Fabian Kosmale 9d22088d93 Remove warning about inability to defer properties
It is generally not actionalbe. In QQC2, we mark properties as deferred,
so that users can replace them with their own custom elements.
We however really don't care about the replacement not being deferrable,
as it will be needed in any case (e.g., Control will create its
contentItem and background in componentComplete if they do not exist
yet). Thus, there is zero gain in ensuring that the replacement is
deferrable.
There are cases where this is not the case: You might want to create a
whole new style, and in turn allow users to override elements there. Or
there might be an item where deferring indeed makes sense.

However, we cannot distinguish those cases so far, and as long as that
is the case, we should not confuse users by complaining about a concept
which is mostly engine internal (the only public documentation about
deferred properties is
https://doc.qt.io/qt-6/qtquickcontrols2-customize.html#considerations-for-custom-styles
and that does not mention the word deferred), where fixing the warning
might not even given them any benefit.

Checking that our standard controls do not prevent deferring is better
checked in tst_sanity statically via qmllint.

Pick-to: 6.4
Fixes: QTBUG-98964
Change-Id: I030e2a2c2a1d99c9cc6cf0d892e0a1d17e048b6a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
2022-06-23 04:48:50 +02:00
..
auto Remove warning about inability to defer properties 2022-06-23 04:48:50 +02:00
baseline Controls: add baseline test for TabBar 2022-06-16 10:05:24 +02:00
benchmarks Use SPDX license identifiers 2022-06-11 08:05:15 +02:00
global
libfuzzer/qml Use SPDX license identifiers 2022-06-11 08:05:15 +02:00
manual Use SPDX license identifiers 2022-06-11 08:05:15 +02:00
system Use SPDX license identifiers 2022-06-11 08:05:15 +02:00
testapplications Use SPDX license identifiers 2022-06-11 08:05:15 +02:00
CMakeLists.txt
README

README

This directory contains autotests and benchmarks based on QTestlib. In order
to run the autotests reliably, you need to configure a desktop to match the
test environment that these tests are written for.

Linux X11:

   * The user must be logged in to an active desktop; you can't run the
     autotests without a valid DISPLAY that allows X11 connections.

   * The tests are run against a KDE3 or KDE4 desktop.

   * Window manager uses "click to focus", and not "focus follows mouse". Many
     tests move the mouse cursor around and expect this to not affect focus
     and activation.

   * Disable "click to activate", i.e., when a window is opened, the window
     manager should automatically activate it (give it input focus) and not
     wait for the user to click the window.