This patch completes the cumulative work done in previous patches.
- Uses qmlRegisterModuleImport() to register styles. This has some
added requirements:
- Each style must now be a QML module -- that is, it must have a
qmldir file.
- As a result of the above, the module must be available within the
QML import path in order to be found.
- The various forms of accepted style names have been reduced down to
one ("Material", "MyStyle", etc). See below for an explanation of
why.
- The following API in QQuickStyle is removed:
addStylePath(), availableStyles(), path(), stylePathList(). These
no longer make sense now that we reuse the existing QML import
system.
- Adds the tst_qquickstyleselector auto test back as "styleimports".
qmlRegisterModuleImport() vs resolvedUrl()
Previously we would use QQuickStyleSelector to select individual
QML files based on which style was set. We'd do this once when
QtQuick.Controls was first imported.
With Qt 6, and the requirement that each style be a proper QML
module, qmlRegisterModuleImport() was introduced. This allows us
to "link" one import with another. For an example of what this
looks like in practice, suppose the style was set to "MyStyle",
and the fallback to "Material". The "QtQuick.Controls" import
will be linked to "MyStyle", "MyStyle" to
"QtQuick.Controls.Material", and as a final fallback (for controls
like Action which only the Default style implements),
"QtQuick.Controls.Material" to "QtQuick.Controls.Default".
This is the same behavior as in Qt 5 (see qquickstyleselector.cpp):
// 1) requested style (e.g. "MyStyle", included in d->selectors)
// 2) fallback style (e.g. "Material", included in d->selectors)
// 3) default style (empty selector, not in d->selectors)
This is a necessary step to enable compilation of QML to C++.
Reducing the set of accepted style names
The problem
In QtQuickControls2Plugin() we need to call
QQuickStylePrivate::init(baseUrl()) in order to detect if the style
is a custom style in QQuickStyleSpec::resolve() (by checking if the
style path starts with the base URL). In Qt 5, init() is called in
QtQuickControls2Plugin::registerTypes(), but in Qt 6 that's too
late, because we need to call qmlRegisterModuleImport() in the
constructor. qmlRegisterModuleImport() itself requires the style to
have already been set in order to create the correct import URI
("QtQuick.Controls.X" for built-in styles, "MyCustomStyle" for
custom styles).
The solution
By reducing the valid forms for style names down to one:
./myapp -style MyStyle
we solve the problem of needing baseUrl() to determine if the
style is a custom style or not, but needing to call it too early
(since we now call qmlRegisterModuleImport() in
QtQuickControls2Plugin(), which itself requires the style to have
already been set). baseUrl() can't have been set before the
constructor is finished.
All of the various forms for _setting_ a style are still valid;
environment variables, qtquickcontrols2.conf, etc.
[ChangeLog][Important Behavior Changes] Custom styles must now have
a qmldir that lists the files that the style implements. For example,
for a style that only implements Button:
---
module MyStyle
Button 1.0 Button.qml
---
In addition, there is now only one valid, case-sensitive form for style
names: "Material", "MyStyle", etc.
These changes are done to help enable the compilation of QML code to
C++, as well as improve tooling capabilities.
[ChangeLog][Important Behavior Changes] The following API was removed:
- QQuickStyle::addStylePath()
- QQuickStyle::availableStyles()
- QQuickStyle::path()
- QQuickStyle::stylePathList()
- QT_QUICK_CONTROLS_STYLE_PATH
This API is no longer necessary and/or able to be provided now that
styles are treated as regular QML modules.
Task-number: QTBUG-82922
Change-Id: I3b281131903c7c3c1cf0616eb7486a872dccd730
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Make sure dynamically created QML components are destroyed when
going out of scope, and print out the error when creation fails.
Change-Id: Ie0ed785780cb861dd057adda8f4da399dd4986d2
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
For example, qtquickcontrols2-label.qml outputs:
- qtquickcontrols2-label.png (Default)
- qtquickcontrols2-material-label.png (Material)
- qtquickcontrols2-universal-label.png (Universal)
This allows us to take screenshots with different styles without
overlapping names and error-prone manual renaming.
Change-Id: Ic475ee0d95539a1122e37780f8cec038e2fc9446
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
For example, don't take screenshots of qtquickcontrols2-material-*.qml
snippets when running with another style than the Material style.
Change-Id: Ifef5b841d16314ba5d131a7d56f57251d6780ae7
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
The component loading code has been adjusted so that it can load
snippets that use either a Window root element too.
This speeds up the test a lot in the CI, and allows us to flatten
the snippet-structure. Set SCREENSHOTS=1 environment variable to
take screenshots.
Change-Id: Ibd9e76befe62044dd1374899f18ea3d8c7ad454b
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
The test is sharing (and showing, and resizing) the same view for
every snippet. In the CI system we keep having issues that sometimes,
after running the test for a while, the window content stops being
resized as appropriate. Considering that QQuickWindow resizes its
content item in resizeEvent(), this probably means that in the CI
the window does sometimes not receive the resize event as appropriate.
Before, the window was left hanging there after taking the very first
screenshot. Now we try to close the window so that each and every
screenshot snippet gets loaded while the window is hidden, shows it,
and waits for it to become visible/active. This will hopefully ensure
that the window will always receive an "initial" resize event.
Task-number: QTBUG-58606
Change-Id: If4b38443cfdc9175f313bf8e70c7daf42d34f687
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Don't show the window until we start taking the screenshots and
actually need a visible window.
Task-number: QTBUG-58606
Change-Id: I2fcab3b54f0faf67588a21e0732d2e6dbcee9194
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This test contains a lot of data rows. Re-creating a QQuickView for
every data row puts a lot of stress on the system. In the new Open
Nebula -based CI, things start consistently exploding after a random
amount of tst_snippets data rows. This change fixes that.
Task-number: QTBUG-58196
Change-Id: I6549944a6d7b2bd384d09ee974bee6423ffe625c
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Add a separate test for non-screenshot snippets and move the screenshot
snippets to their own folder.
Change-Id: Ic3e7370321e346b83f7df42205e204d1265ce5b0
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
And add QT_NO_FOREACH define to .qmake.conf.
Now QuickControls2 is 'foreach' free.
Change-Id: I98695258859decadae6fd2f23f5f6f5ef2b0550f
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
So that we don't refer to internal types, as these make copying and
pasting snippets difficult.
Change-Id: I6f3b943d2eed48beb7a64690c707924e2c5a8078
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
Most doc example snippet files were renamed in ca8f57f, the test needs
to be updated accordingly.
Change-Id: I633ace53b7aaf8853b6eae5c8c60a90c2ae38dc2
Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
They are part of the documentation, but just auto-tested to ensure that
they are actually creatable and don't throw warnings. Therefore the
logical place is in the doc/snippets folder instead of somewhere in the
tests/ tree.
Change-Id: Id79a19890f7457ef277e7434a3fc6b6fb20eaa25
Reviewed-by: Mitch Curtis <mitch.curtis@theqtcompany.com>
Change-Id: I9c4801ac91c52d487e98a99ff4d38e133f0679a3
Reviewed-by: Liang Qi <liang.qi@theqtcompany.com>
Reviewed-by: Mitch Curtis <mitch.curtis@theqtcompany.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com>
This is going to include all snippets used in the documentation,
which will be then automatically tested for vality, and at the
same time the respective screenshots are automatically generated.
Notice that copying the screenshots over to src/doc/images is still
a manual step. This is fully intentional because the screenshot
results may vary quite a bit across different platforms due to
different fonts and so on. FWIW, my personal favorite for generating
the screenshots is OS X.
Change-Id: I72b299f15b498abc1afd0a686c56d43159bee775
Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
Mitch Curtis
J-P Nurmi
Anton Kudryavtsev
Mitch Curtis
J-P Nurmi
J-P Nurmi
Frederik Gladhorn