Modifications apportées à Qt Quick Controls

Qt 6 résultent d’un effort délibéré visant à rendre le framework plus efficace et plus facile à utiliser.

Nous nous efforçons de maintenir la compatibilité de toutes les API publiques à chaque nouvelle version. Certains changements étaient inévitables pour améliorer le framework Qt.

Dans cette rubrique, nous résumons ces modifications dans Qt Quick Controls et fournissons des conseils pour les prendre en compte.

Migration depuis Qt Quick Controls 1

Qt Quick Controls 1 a été déprécié dans Qt 5.11 et supprimé de Qt 6.0. Utilisez plutôt Qt Quick Controls (anciennement Qt Quick Controls 2). Pour plus d'informations, consultez la rubrique « Qt 5.15 : Qt Quick Controls vs Qt Quick Controls 1 » dans la documentation Qt 5.

Modifications apportées à l’enregistrement des types

Qt Quick Controls a subi d'importants changements, principalement internes, dans Qt 6. En tirant parti de l'enregistrement des types amélioré introduit dans Qt 5.15, nous ouvrons la voie à la compilation des fichiers QML du module en C++ et permettons aux outils de gagner en efficacité. En particulier, le modèle de code QML d’ Qt Creator devrait disposer d’une vue d’ensemble plus complète des types, ce qui rendra la complétion et la vérification des erreurs du code d’ Qt Quick Controls s plus fiables. Les outils d’analyse statique tels que qmllint et qmlformat en bénéficient également, car ils prennent désormais en compte les types déclarés au moment de la compilation en C++.

En raison de ces changements, certaines choses se font désormais un peu différemment.

Les styles personnalisés sont désormais de véritables modules QML

Pour permettre l’enregistrement des types à la compilation, chaque style d’ Qt Quick Controls est désormais un véritable module QML. Auparavant, une simple Button.qml suffisait pour créer son propre style. Bien que pratique, cette approche nécessitait une API non standard, ce qui impliquait à son tour une adaptation des outils tels que Qt Designer.

Désormais, tous les types QML implémentés par un style doivent être déclarés dans le fichier `qmldir` de ce style :

module MyStyle
Button 1.0 Button.qml

En harmonisant cette approche avec le reste de l'univers QML, les styles deviennent plus familiers aux développeurs et, espérons-le, plus faciles à comprendre pour les débutants. En conséquence, l'API suivante a dû être supprimée :

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

Étant donné que les styles doivent désormais se trouver dans le chemin d'importation du moteur QML, comme n'importe quel autre module QML, il n'est plus nécessaire ni possible de prendre en charge cette API.

Noms de styles

De plus, il n’existe désormais qu’une seule forme valide (sensible à la casse) pour les noms de styles : « Material », « MyStyle », etc. Autrement dit, le nom du style doit correspondre exactement au nom du module QML. Cela s’applique également aux sélecteurs de fichiers, où auparavant, tous les noms de styles étaient en minuscules. Par exemple, alors que la structure suivante était valide pour un projet Qt 5 :

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

Dans Qt 6, +material devient +Material:

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

Toutes les méthodes existantes permettant d’ exécuter une application avec un style spécifique sont toujours prises en charge.

Sélection de style à l’exécution et à la compilation

L’importation d’un style revêt désormais une importance particulière en raison du fonctionnement interne des importations. Auparavant, l’importation de ` QtQuick.Controls ` enregistrait les types de contrôles du style actuel auprès du moteur QML :

import QtQuick.Controls

Nous appelons cela la sélection de style à l’exécution, car le style est sélectionné lors de l’exécution.

L'importation explicite de ` QtQuick.Controls.Material ` exposait alors simplement toute API supplémentaire fournie par ce style (par exemple, le type `Material` associé) :

import QtQuick.Controls.Material

Désormais, l’importation explicite d’un style effectue les deux opérations.

Concrètement, cela signifie que les types de contrôles (tels que Button) du dernier style importé seront utilisés. C’est ce que l’on appelle la sélection de style à la compilation.

Cela a des implications pour le code existant. Concrètement, si votre application prend en charge plusieurs styles, déplacez ces importations dans leurs propres fichiers QML sélectionnés au niveau du fichier.

Par exemple, si vous avez l’ main.qml tion suivante :

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.
}

Vous pouvez déplacer le code commun dans un composant « base » :

// MainWindow.qml

import QtQuick.Controls

ApplicationWindow {}

Ensuite, ajoutez un sous-répertoire « +Material » et, à l’intérieur, placez le code spécifique à Material dans « MainWindow.qml » :

// +Material/MainWindow.qml

import QtQuick.Controls.Material

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

Procédez de la même manière pour Universal :

// +Universal/MainWindow.qml

import QtQuick.Controls.Universal

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

Ensuite, dans main.qml:

import QtQuick.Controls

MainWindow {
    width: 600
    height: 400
    visible: true

    // Child items, etc.
}

Voir aussi : Utilisation des sélecteurs de fichiers avec Qt Quick Controls.

Style par défaut

Le style par défaut a été renommé « Basic », car il n’est plus le style par défaut. À la place, le style par défaut est désormais choisi en fonction de la plateforme pour laquelle Qt a été compilé :

• Android : style Material
• Linux : style Fusion
• macOS : style macOS
• Windows : style Windows
• Toutes les autres plateformes : style « Basic »

Par conséquent, les applications qui ne spécifiaient pas de style dans Qt 5 et qui comportaient des contrôles personnalisés doivent explicitement spécifier le style « Basic » dans Qt 6 afin de garantir que ces contrôles conservent l'apparence et le comportement qu'ils avaient sous Qt 5.

Palette

L'API de la palette a été déplacée vers QQuickItem. Les différentes API qui utilisent les palettes dans Qt Quick Controls restent inchangées.

Contrôles

Modifications apportées à ApplicationWindow

Les propriétés « overlay » obsolètes et l’API « attached » ont été supprimées. Utilisez plutôt le type « attached » de Overlay.

Modifications apportées à ComboBox

La propriété « pressed » est désormais en lecture seule. Pour modifier l'état visuel « enfoncé » d'un ComboBox, utilisez plutôt la propriété « down ».

Modifications apportées à Container

La fonction obsolète ` removeItem(var) ` a été supprimée. Vous pouvez désormais utiliser ` removeItem` (Item) ou ` takeItem` (int) à la place.

Modifications apportées à la boîte de dialogue

DialogLes signaux « accepted() » et « rejected() » de la boîte de dialogue sont désormais émis avant « closed() » lors de l'appel des fonctions « done() », « accept() » et « reject() ».

Modifications apportées au menu

La fonction obsolète ` removeItem(var) ` a été supprimée. Vous pouvez désormais utiliser ` removeItem(Item)` ou ` takeItem(int)` à la place.

Modifications apportées à ToolTip

ToolTipLe délai d'expiration de la fonction « tooltip » ne commence désormais à courir qu’après l’émission de la fonction opened(). Cela a pour conséquence que les info-bulles avec des transitions « enter » restent visibles pendant toute la durée définie par la propriété « timeout ». Elles restent donc visibles un peu plus longtemps qu’auparavant ; il peut donc être utile de vérifier visuellement les info-bulles dans votre application et d’ajuster les délais d’expiration si nécessaire.

Modifications apportées à StackView

La valeur d’énumération StackView.Transition a été dépréciée. L’argument « operation » peut être omis afin d’utiliser la transition par défaut pour toute opération donnée.

Modifications apportées à Tumbler

implicitWidth et ` implicitHeight ` doivent désormais être fournis pour ` contentItem` de ` Tumbler`, ce qui assure la cohérence avec tous les autres contrôles.