Changements apportés aux contrôles Qt Quick

Qt 6 est le résultat d'un effort conscient pour rendre le cadre de travail plus efficace et plus facile à utiliser.

Nous essayons de maintenir la compatibilité de toutes les API publiques dans chaque version. Certains changements étaient inévitables dans un effort pour faire de Qt un meilleur framework.

Dans cette rubrique, nous résumons ces changements dans Qt Quick Controls, et fournissons des conseils pour les gérer.

Migration à partir de Qt Quick Controls 1

Qt Quick Controls 1 était obsolète dans Qt 5.11 et est supprimé dans Qt 6.0. Utilisez Qt Quick Controls (précédemment connu sous le nom de Qt Quick Controls 2) à la place. Pour plus d'informations, reportez-vous à la rubrique Qt 5 .15 : Qt Quick Controls vs Qt Quick Controls 1 dans la documentation Qt 5.

Changements dans l'enregistrement des types

Qt Quick Controls a subi quelques changements importants, principalement internes, dans Qt 6. En utilisant l'enregistrement de type amélioré introduit dans Qt 5.15, nous ouvrons la voie à la compilation des fichiers QML du module en C++ et permettons à l'outillage de devenir plus efficace. En particulier, le modèle de code QML de Qt Creator devrait avoir une image plus complète des types, ce qui rendra son achèvement et la vérification des erreurs du code Qt Quick Controls plus fiables. Les outils d'analyse statique tels que qmllint et qmlformat bénéficient également de la prise en compte des types qui sont désormais déclarés au moment de la compilation en C++.

À la suite de ces changements, certaines choses sont faites un peu différemment.

Les styles personnalisés sont désormais des modules QML à part entière

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

Désormais, tous les types QML qu'un style met en œuvre doivent être déclarés dans le fichier qmldir de ce style :

module MyStyle
Button 1.0 Button.qml

En unifiant cela avec le reste du monde 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

Maintenant que les styles doivent être trouvés dans le chemin d'importation du moteur QML comme tout autre module QML, il n'est plus nécessaire ni possible de prendre en charge cette API.

Noms des styles

En outre, il n'existe plus qu'une seule forme valide, sensible à la casse, pour les noms de style : "Material", "MyStyle", etc. En d'autres termes, le nom du style doit correspondre exactement au nom du module QML. Cela s'applique également aux sélecteurs de fichiers, alors qu'auparavant, tous les noms de style étaient en minuscules. Par exemple, 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 façons existantes d'exécuter une application avec un style spécifique sont toujours prises en charge.

Sélection de style au moment de l'exécution et de la compilation

L'importation d'un style a désormais une signification supplémentaire en raison de la manière dont les importations fonctionnent en interne. Auparavant, l'importation de QtQuick.Controls enregistrait les types de contrôle du style actuel dans le moteur QML :

import QtQuick.Controls

Nous parlons ici de sélection de style au moment de l'exécution, car le style est sélectionné au moment 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 joint) :

import QtQuick.Controls.Material

Désormais, l'importation explicite d'un style fait les deux.

Cela signifie effectivement que les types de contrôle (comme Button) du dernier style importé seront utilisés. C'est ce que nous appelons la sélection de style à la compilation.

Cela a des implications pour le code existant. En effet, si votre application supporte plus d'un style, déplacez ces importations dans leurs propres fichiers QML qui sont sélectionnés par fichier.

Par exemple, si vous avez l'application suivante 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.
}

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 dans ce sous-répertoire, ajoutez le code spécifique au matériau dans MainWindow.qml:

// +Material/MainWindow.qml

import QtQuick.Controls.Material

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

Faites de même pour Universal :

// +Universal/MainWindow.qml

import QtQuick.Controls.Universal

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

Puis, dans main.qml:

import QtQuick.Controls

MainWindow {
    width: 600
    height: 400
    visible: true

    // Child items, etc.
}

Voir aussi : Utilisation de sélecteurs de fichiers avec les contrôles Qt Quick .

Style par défaut

Le style par défaut a été renommé "Basic", car ce n'est plus le style par défaut. Au lieu de cela, le style par défaut est maintenant choisi en fonction de la plateforme pour laquelle Qt a été construit :

• Android : Style matériel
• Linux : Style Fusion
• macOS : Style macos
• Windows : Style Windows
• Toutes les autres plateformes : Style Basic

Par conséquent, les applications qui n'ont pas spécifié de style dans Qt 5 et qui ont des contrôles personnalisés doivent explicitement spécifier le style Basic dans Qt 6 pour s'assurer que ces contrôles se présentent et se comportent comme ils le faisaient avec Qt 5.

Palette

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

Contrôles

Changements apportés à ApplicationWindow

Les propriétés de recouvrement et l'API attachée, obsolètes, ont été supprimées. Utilisez plutôt le type attaché Overlay.

Modifications apportées à ComboBox

La propriété pressed est désormais en lecture seule. Pour modifier l'état visuel enfoncé d'une ComboBox, utilisez la propriété down à la place.

Modifications apportées à Container

La fonction removeItem(var), obsolète, a été supprimée. removeItem Les fonctions (Item) ou takeItem(int) peuvent être utilisées à la place.

Modifications apportées à Dialog

DialogLes signaux accepted() et rejected() sont maintenant émis avant closed() lors de l'appel à done(), accept() et reject().

Changements apportés à Menu

La fonction removeItem(var), obsolète, a été supprimée. removeItem Elle peut être remplacée par les fonctions takeItem(Item) ou (int).

Modifications apportées à ToolTip

ToolTipLe délai d'attente de la ToolTip ne commence à présent qu'après l'émission de opened(). Cela signifie que les infobulles avec des transitions d'entrée sont visibles pendant toute la durée de la propriété timeout. Cela signifie qu'elles sont visibles un peu plus longtemps qu'auparavant, il peut donc être utile de vérifier visuellement les infobulles dans votre application et d'ajuster les délais si nécessaire.

Modifications apportées à StackView

La valeur de l'enum StackView.Transition est obsolète. L'argument operation peut être omis afin d'utiliser la transition par défaut pour une opération donnée.

Modifications apportées à Tumbler

implicitWidth La valeur de l'énumération de Tumbler et de implicitHeight doit maintenant être fournie pour 's contentItem, ce qui la rend cohérente avec tous les autres contrôles.