QML pour les programmeurs Qt

Aperçu

Bien que l'utilisation de QML ne requière aucune connaissance de Qt, si vous êtes déjà familier de Qt, vos connaissances seront directement exploitables pour l'apprentissage et l'utilisation de QML. Bien sûr, une application avec une interface utilisateur définie en QML utilise aussi Qt pour toute la logique hors interface utilisateur.

Concepts familiers

QML fournit un accès direct aux concepts Qt suivants.

• QAction - le type action.
• Les signaux et slots de QObject - disponibles comme fonctions à appeler en JavaScript.
• Les propriétés de QObject - disponibles comme variables dans JavaScript.
• QWidget - QDeclarativeView est un widget d'affichage pour QML.
• Modèles Qt - utilisés directement dans la liaison de données (QAbstractItemModel).

La connaissance de Qt est requise pour étendre QML au C++ ainsi que pour l'intégration de QML avec un code d'interface utilisateur Qt existant.

Éléments QML comparés aux QWidgets

Les éléments QML sont très similaires aux QWidget : ils définissent l'aspect de l'interface utilisateur. Notez que bien que les QWidget ne sont traditionnellement pas utilisés pour définir l'aspect des vues déléguées, les éléments QML peuvent l'être.

Il y a trois types différents de QWidget :

• les widgets simples qui ne sont pas utilisés comme parents (QLabel, QCheckBox, QToolButton, etc.) ;
• les widgets parents qui sont normalement utilisés comme parents d'autres widgets (QGroupBox, QStackedWidget, QTabWidget, etc.) ;
• les widgets composés qui sont composés de plusieurs widgets enfants (QComboBox, QSpinBox, QFileDialog, QTabWidget, etc.).

Les éléments QML remplissent aussi ces fonctions. Chaque catégorie est détaillée ci-dessous.

Widgets simples

La règle la plus importante à retenir lors de l'implémentation d'un nouveau QDeclarativeItem en C++ est qu'il ne doit contenir aucune indication sur l'aspect visuel, qui ne doit être défini que lors de l'utilisation de l'élément par QML.

Par exemple, imaginez que vous voulez un élément bouton réutilisable. Si vous décidez alors d'écrire une sous-classe de QDeclarativeItem pour implémenter un bouton, tout comme QToolButton hérite de QWidget dans le même but, en suivant la règle ci-dessus, votre QDeclarativeButton n'aura pas d'apparence - juste les notions d'activé, déclenché, etc.

Mais il existe déjà une classe de Qt qui fait cela : QAction.

QAction est l'essence, indépendante de l'interface utilisateur, des éléments QPushButton, QCheckBox, QMenu, QToolButton et autres widgets visuels qui sont généralement liés à une QAction.

Donc, le travail d'implémentation d'une abstraction d'une checkbox pour QML est déjà effectué - c'est QAction. L'aspect d'une action, l'apparence d'un bouton, la transition entre les états et la réponse exacte à la souris, au clavier ou au toucher doit être défini dans QML.

Afin d'illustrer cela, il est important de noter que QDeclarativeTextEdit est construit sur QTextControl, QDeclarativeWebView est construit sur QWebPage et ListView utilise QAbstractItemModel, tout comme QTextEdit, QWebView et QListView sont construits sur ces mêmes composants découplés de l'interface utilisateur.

L'encapsulation de l'aspect que QWidget donne est importante et le concept QML des composants a le même objectif. Si vous construisez une suite complète d'applications qui nécessite un aspect cohérent, vous devriez construire un ensemble de composants réutilisables avec l'aspect que vous souhaitez.

Donc, pour l'implémentation de votre bouton réutilisable, vous construirez simplement un composant QML.

Widgets parents

Les widgets parents fournissent chacun une méthode générique pour s'interfacer avec un ou plusieurs autres widgets arbitraires. Un QTabWidget fournit une interface pour plusieurs « pages », l'une d'entre elles étant toujours visible, ainsi qu'un mécanisme de sélection (le QTabBar). Une QScollArea fournit des barres de défilement autour d'un widget trop grand pour être contenu dans l'espace disponible.

Presque tous ces composants peuvent être créés directement en QML. Dans de rares cas demandant une gestion particulière des événements, comme Flickable, une implémentation C++ est requise.

Par exemple, imaginez que vous décidiez de créer un widget à onglets générique qui puisse être inséré dans votre suite applicative chaque fois que les informations sont tellement nombreuses qu'elles doivent être divisées en plusieurs pages.

Une différence significative entre le concept de parents de QML et celui de QWidget est que même si les éléments enfants sont positionnés relativement à leur parent, ils ne sont pas obligatoirement contenus intégralement dans leur parent - bien que la propriété de masquage (ou clipping) de l'élément enfant le permet lorsque c'est nécessaire. Cette différence a des conséquences importantes, par exemple :

• une ombre ou une surbrillance autour du widget peut être un enfant de ce widget ;
• les effets de particules peuvent sortir de l'objet d'origine ;
• les animations de transition peuvent « cacher » les éléments en les déplaçant en dehors des limites de l'écran.

Widgets composés

Certains widgets fournissent des fonctionnalités en combinant d'autres widgets en tant que « détails d'implémentation », et en donnant accès à une interface de programmation de plus haut niveau pour cet ensemble composite. Par exemple, QSpinBox est une ligne d'édition avec des boutons pour diminuer/augmenter la valeur éditée. QFileDialog utilise un ensemble de widgets pour permettre à l'utilisateur de trouver et sélectionner un nom de fichier.

Lors du développement d'éléments QML, vous pouvez choisir de faire la même chose : construire un élément composé d'autres éléments qui sont déjà définis.

Il ne faut pas oublier, pour des compositions, de considérer les animations et transitions possibles que les utilisateurs de la composition vont vouloir employer. Par exemple, une spinbox peut nécessiter une transition douce depuis un élément Text arbitraire, donc votre élément spinbox devra être suffisamment flexible pour permettre une telle animation.

Éléments QML comparés aux QGraphicsWidgets

La principale différence entre les éléments QML et les QGraphicsWidgets se situe dans l'usage pour lequel ils sont prévus. Les détails techniques de l'implémentation sont similaires mais en pratique ils diffèrent car les éléments QML sont conçus pour un usage déclaratif et de composition alors que les QGraphicsWidgets sont conçus pour un usage impératif et plus intégré. Les éléments QML et QGraphicsWidgets héritent de QGraphicsObject et peuvent coexister. Les différences se situent dans le système de disposition (layout) et dans l'interfaçage avec d'autres composants. Notez que comme les QGraphicsWidgets tendent à être des constructions tout-en-un, l'équivalent d'un QGraphicsWidget peut être un ensemble d'éléments QML composé autour de plusieurs fichiers QML mais qui peut être chargé et utilisé comme un seul QGraphicsObject en C++.

Les QGraphicsWidget sont habituellement conçus pour être disposés avec des QGraphicsLayout. QML n'utilise pas les QGraphicsLayout, car les dispositions Qt ne fonctionnent pas efficacement avec les interfaces utilisateur fluides et animées, donc l'interface géométrique est l'une des différences principales. Lors de l'écriture d'éléments QML, vous permettez aux designers de placer leurs rectangles en utilisant les géométries absolues, les liens et ancres (prêts à l'usage lorsque vous héritez QDeclarativeItem) et vous n'utilisez pas les dispositions ni les indications de taille. Si des indications de taille sont opportunes, alors placez-les dans la documentation QML pour que les designers puissent savoir comment utiliser au mieux l'élément tout en gardant le contrôle total de l'aspect.

L'autre différence principale est que les QGraphicsWidgets ont tendance à suivre le modèle widget, c'est-à-dire à être un ensemble autonome composé de l'interface utilisateur et de la logique de fonctionnement. Au contraire, les primitives QML sont habituellement des éléments spécialisés ne traitant pas un cas d'usage par eux-mêmes mais étant intégrés dans l'équivalent du widget dans le fichier QML. Donc, lors de l'écriture d'un élément QML, essayez d'éviter de coder la logique de l'interface utilisateur ou de composer des éléments visuels dans l'élément. Essayez plutôt d'écrire des primitives plus généralistes qui permettent à l'apparence et à la logique de l'interface utilisateur d'être codées en QML.

Ces deux différences sont causées par des méthodes d'interaction différentes. QGraphicsWidget est une sous-classe de QGraphicsObject qui rend fluide le développement d'interface utilisateur à partir du C++ et QDeclarativeItem est une sous-classe de QGraphicsObject qui rend fluide le développement d'interface utilisateur à partir de QML. Par conséquent, la différence est principalement l'interface exposée et le design des éléments qui en découle (les primitives Declarative pour QML et rien pour QGraphicsWidget, car vous devez écrire votre propre logique d'interface utilisateur de la sous-classe).

Si vous souhaitez utiliser à la fois QML et le C++ pour coder une interface utilisateur, par exemple pour faciliter la transition, il est recommandé d'utiliser les sous-classes de QDeclarativeItem (bien que vous puissiez également utiliser QGraphicsWidget). Pour permettre un usage plus facile du C++, donnez un élément racine LayoutItem à chaque composant C++, et chargez les « widget » QML individuels (chacun pouvant comprendre plusieurs fichiers, et contenant un ensemble autonome d'interface utilisateur et de logique associée) dans votre scène pour remplacer les QGraphicsWidgets les uns après les autres.

Remerciements

Merci à Alexandre Laurent pour la traduction ainsi qu'à Ilya Diallo, Jonathan Courtois et Claude Leloup pour leur relecture !