Changes to Qt Quick Controls | Qt Quick Controls 6.7.3
Description: Migrate Qt Quick Controls to Qt 6.

- Qt 6.7
- Qt Quick Controls
- Changes to Qt Quick Controls
- Qt 6.7.3 Reference Documentation

# Changes to Qt Quick Controls

Qt 6 is a result of the conscious effort to make the framework more efficient and easy to use.

We try to maintain compatibility for all the public APIs in each release. Some changes were inevitable in an effort to make Qt a better framework.

In this topic we summarize those changes in Qt Quick Controls, and provide guidance to handle them.

## Migrating from Qt Quick Controls 1

Qt Quick Controls 1 was deprecated in Qt 5.11 and is removed from Qt 6.0. Use Qt Quick Controls (previously known as Qt Quick Controls 2) instead. For more information, refer to the Qt 5.15: Qt Quick Controls vs Qt Quick Controls 1 topic in the Qt 5 documentation.

## Type registration changes

Qt Quick Controls has undergone some large, mostly internal changes in Qt 6. By making use of the improved type registration introduced in Qt 5.15, we pave the way for compilation of the module's QML files to C++ and enable tooling to become more effective. In particular, Qt Creator's QML code model should have a more complete picture of types, making its completion and error checking of Qt Quick Controls code more reliable. Static analysis tools like qmllint and qmlformat also benefit by becoming aware of the types that are now declared at compile time in C++.

As a result of these changes, some things are done a little differently.

### Custom styles are now proper QML modules

To enable compile time type registration, each Qt Quick Controls style is now a proper QML module. Previously, a single `Button.qml` was sufficient to create your own style. While convenient, this required some non-standard API, which in turn required adaptation in tooling like Qt Designer.

Now, all QML types that a style implements must be declared in that style's qmldir file:

     module MyStyle
     Button 1.0 Button.qml

By unifying this with the rest of the QML world, styles become more familiar to developers and hopefully easier to understand for beginners. As a consequence, the following API had to be removed:

- QQuickStyle::addStylePath()
- QQuickStyle::availableStyles()
- QQuickStyle::path()
- QQuickStyle::stylePathList()
- QT_QUICK_CONTROLS_STYLE_PATH

Now that the styles are required to be found in the QML engine's import path like any other QML module, it is no longer necessary or possible to support this API.

#### Style names

In addition, there is now only one valid, case-sensitive form for style names: "Material", "MyStyle", and so on. That is: the style name must exactly match the name of the QML module. This also applies to file selectors, where previously, all style names were lower case. For example, where the following was a valid structure for a Qt 5 project:

     MyProject
     ├── main.qml
     ├── HomePage.qml
     └── +material
         └───HomePage.qml

In Qt 6, `+material` becomes `+Material`:

     MyProject
     ├── main.qml
     ├── HomePage.qml
     └── +Material
         └───HomePage.qml

All of the existing ways to run an application with a specific style are still supported.

### Runtime and compile time style selection

Importing a style now has extra meaning due to the way that imports work internally. Previously, importing `QtQuick.Controls` would register the control types from the current style with the QML engine:

     import QtQuick.Controls

We refer to this as runtime style selection, as the style is selected at runtime.

Explicitly importing `QtQuick.Controls.Material` would then simply expose any extra API provided by that style (for example, the attached Material type):

     import QtQuick.Controls.Material

Now, explicitly importing a style does both.

This effectively means that the control types (like Button) from the last imported style will be used. We refer to this as compile time style selection.

This has implications for existing code. Namely, if your application supports more than one style, move these imports into their own QML files that are file-selected.

For example, if you have the following `main.qml`:

     import QtQuick.Controls
     import QtQuick.Controls.Material
     import QtQuick.Controls.Universal

     ApplicationWindow {
         width: 600
         height: 400
         visible: true

         Material.theme: darkMode ? Material.Dark : Material.Light
         Universal.theme: darkMode ? Universal.Dark : Universal.Light

         // Child items, etc.
     }

You can move the common code into a "base" component:

     // MainWindow.qml

     import QtQuick.Controls

     ApplicationWindow {}

Then, add a `+Material` subdirectory, and in it, add the Material-specific code into `MainWindow.qml`:

     // +Material/MainWindow.qml

     import QtQuick.Controls.Material

     ApplicationWindow {
         Material.theme: darkMode ? Material.Dark : Material.Light
     }

Do the same for Universal:

     // +Universal/MainWindow.qml

     import QtQuick.Controls.Universal

     ApplicationWindow {
         Universal.theme: darkMode ? Universal.Dark : Universal.Light
     }

Then, in `main.qml`:

     import QtQuick.Controls

     MainWindow {
         width: 600
         height: 400
         visible: true

         // Child items, etc.
     }

See also: Using File Selectors with Qt Quick Controls.

## Default Style

The Default style was renamed to "Basic", as it is no longer the default style. Instead, the default style is now chosen based on the platform that Qt was built for:

- Android: Material Style
- Linux: Fusion Style
- macOS: macos Style
- Windows: Windows Style
- All other platforms: Basic Style

Therefore, applications that didn't specify a style in Qt 5 and have customized controls should explicitly specify the Basic style in Qt 6 to ensure that those controls look and behave as they did with Qt 5.

## Palette

The palette API was moved to QQuickItem. The various APIs that use palettes in Qt Quick Controls are unchanged.

## Controls

### Changes to ApplicationWindow

The deprecated overlay properties and attached API were removed. Use the Overlay attached type instead.

### Changes to ComboBox

The pressed property is now read-only. To modify the visual pressed state of a ComboBox, use the down property instead.

### Changes to Container

The deprecated `removeItem(var)` function was removed. removeItem(Item) or takeItem(int) can be used instead.

### Changes to Dialog

Dialog's accepted() and rejected() signals are now emitted before closed() when calling done(), accept() and reject().

### Changes to Menu

The deprecated `removeItem(var)` function was removed. removeItem(Item) or takeItem(int) can be used instead.

### Changes to ToolTip

ToolTip's timeout now begins only after opened() has been emitted. This results in tooltips with enter transitions being visible for the entire duration of the timeout property. This means that they are visible slightly longer than they were before, so it may be worthwhile to visually check tooltips in your application and adjust timeouts if necessary.

### Changes to StackView

The StackView.Transition enum value was deprecated. The operation argument can be omitted in order to use the default transition for any given operation.

### Changes to Tumbler

implicitWidth and implicitHeight must now be provided for Tumbler's contentItem, making it consistent with all other controls.