1// Copyright (C) 2020 The Qt Company Ltd.
2// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
5 \page qtquickcontrols-changes-qt6.html
6 \title Changes to Qt Quick Controls
7 \ingroup changes-qt-5-to-6
8 \brief Migrate Qt Quick Controls to Qt 6.
10 Qt 6 is a result of the conscious effort to make the framework more
11 efficient and easy to use.
13 We try to maintain compatibility for all the public APIs in each release.
14 Some changes were inevitable in an effort to make Qt a better framework.
16 In this topic we summarize those changes in Qt Quick Controls, and provide
17 guidance to handle them.
19 \section1 Migrating from Qt Quick Controls 1
21 Qt Quick Controls 1 was deprecated in Qt 5.11 and is removed from
22 Qt 6.0. Use Qt Quick Controls (previously known as Qt Quick Controls 2)
23 instead. For more information, refer to the
24 \l{Qt 5.15: Qt Quick Controls vs Qt Quick Controls 1} topic in the Qt 5
27 \section1 Type registration changes
29 Qt Quick Controls has undergone some large, mostly internal changes in Qt
30 6. By making use of the improved type registration introduced in Qt 5.15,
31 we pave the way for compilation of the module's QML files to C++ and enable
32 tooling to become more effective. In particular, Qt Creator's QML code
33 model should have a more complete picture of types, making its completion
34 and error checking of Qt Quick Controls code more reliable. Static analysis
35 tools like qmllint and qmlformat also benefit by becoming aware of the
36 types that are now declared at compile time in C++.
38 As a result of these changes, some things are done a little differently.
40 \section2 Custom styles are now proper QML modules
42 To enable compile time type registration, each Qt Quick Controls style is
43 now a proper QML module. Previously, a single \c Button.qml was sufficient
44 to create your own style. While convenient, this required some non-standard
45 API, which in turn required adaptation in tooling like Qt Designer.
47 Now, all QML types that a style implements must be declared in that style's
56 TODO: Once we have documentation for the CMake function qt6_add_qml_module,
57 this would be a good place to link to it, stating that you don't have to
58 manually write the qmldir files.
61 By unifying this with the rest of the QML world, styles become more
62 familiar to developers and hopefully easier to understand for beginners. As
63 a consequence, the following API had to be removed:
66 \li QQuickStyle::addStylePath()
67 \li QQuickStyle::availableStyles()
68 \li QQuickStyle::path()
69 \li QQuickStyle::stylePathList()
70 \li QT_QUICK_CONTROLS_STYLE_PATH
73 Now that the styles are required to be found in the QML engine's import
74 path like any other QML module, it is no longer necessary or possible to
79 In addition, there is now only one valid, case-sensitive form for style
80 names: "Material", "MyStyle", and so on. That is: the style name must
81 exactly match the name of the QML module. This also applies to file
82 selectors, where previously, all style names were lower case. For example,
83 where the following was a valid structure for a Qt 5 project:
93 In Qt 6, \c +material becomes \c +Material:
103 All of the existing ways to \l {Using Styles in Qt Quick Controls}{run an
104 application with a specific style} are still supported.
106 \section2 Runtime and compile time style selection
108 Importing a style now has extra meaning due to the way that imports work
109 internally. Previously, importing \c QtQuick.Controls would register the
110 control types from the current style with the QML engine:
113 import QtQuick.Controls
116 We refer to this as runtime style selection, as the style is selected at
119 Explicitly importing \c QtQuick.Controls.Material would then simply expose
120 any extra API provided by that style (for example, the attached Material
124 import QtQuick.Controls.Material
127 Now, explicitly importing a style does both.
129 This effectively means that the control types (like Button) from the last
130 imported style will be used. We refer to this as compile time style
133 This has implications for existing code. Namely, if your application
134 supports more than one style, move these imports into their own QML files
135 that are file-selected.
137 For example, if you have the following \c main.qml:
140 import QtQuick.Controls
141 import QtQuick.Controls.Material
142 import QtQuick.Controls.Universal
149 Material.theme: darkMode ? Material.Dark : Material.Light
150 Universal.theme: darkMode ? Universal.Dark : Universal.Light
156 You can move the common code into a "base" component:
161 import QtQuick.Controls
166 Then, add a \c +Material subdirectory, and in it, add the Material-specific code into \c MainWindow.qml:
169 // +Material/MainWindow.qml
171 import QtQuick.Controls.Material
174 Material.theme: darkMode ? Material.Dark : Material.Light
178 Do the same for Universal:
181 // +Universal/MainWindow.qml
183 import QtQuick.Controls.Universal
186 Universal.theme: darkMode ? Universal.Dark : Universal.Light
190 Then, in \c main.qml:
193 import QtQuick.Controls
204 See also: \l {Using File Selectors with Qt Quick Controls}.
206 \section1 Default Style
208 The Default style was renamed to "Basic", as it is no longer the default
209 style. Instead, the default style is now chosen based on the platform
210 that Qt was built for:
213 \li Android: \l {Material Style}
214 \li Linux: \l {Fusion Style}
215 \li macOS: \l {macos Style}
216 \li Windows: \l {Windows Style}
217 \li All other platforms: \l {Basic Style}
220 Therefore, applications that didn't specify a style in Qt 5 and have customized
221 controls should \l {Using Styles in Qt Quick Controls}{explicitly specify}
222 the Basic style in Qt 6 to ensure that those controls look and behave as
227 The palette API was moved to QQuickItem. The various APIs that use palettes
228 in Qt Quick Controls are unchanged.
232 \section2 Changes to ApplicationWindow
234 The deprecated overlay properties and attached API were removed. Use the
235 \l Overlay attached type instead.
237 \section2 Changes to ComboBox
239 The \l {ComboBox::}{pressed} property is now read-only. To modify the
240 visual pressed state of a ComboBox, use the \l {ComboBox::}{down} property
243 \section2 Changes to Container
245 The deprecated \c removeItem(var) function was removed.
246 \l {Container::}{removeItem(Item)} or \l {Container::}{takeItem(int)} can
249 \section2 Changes to Dialog
251 \l {Dialog}'s \l {Dialog::}{accepted()} and \l {Dialog::}{rejected()}
252 signals are now emitted before \l {Popup::}{closed()} when calling
253 \l {Dialog::}{done()}, \l {Dialog::}{accept()} and \l {Dialog::}{reject()}.
255 \section2 Changes to Menu
257 The deprecated \c removeItem(var) function was removed.
258 \l {Menu::}{removeItem(Item)} or \l {Menu::}{takeItem(int)} can be used
261 \section2 Changes to ToolTip
263 \l {ToolTip}'s timeout now begins only after \l {Popup::}{opened()} has
264 been emitted. This results in tooltips with enter transitions being visible
265 for the entire duration of the timeout property. This means that they are
266 visible slightly longer than they were before, so it may be worthwhile to
267 visually check tooltips in your application and adjust timeouts if
270 \section2 Changes to StackView
272 The StackView.Transition enum value was deprecated. The operation argument
273 can be omitted in order to use the default transition for any given
276 \section2 Changes to Tumbler
278 \l {Item::}{implicitWidth} and \l {Item::}{implicitHeight} must now be
279 provided for \l {Tumbler}'s \l {Control::}{contentItem}, making it
280 consistent with all other controls.