Qt 6 en 2020 ?

Les premiers plans des développeurs sont d'ores et déjà dévoilés

Le Qt Contributors Summit s’est achevé cette semaine. La conférence rassemblait une centaine de contributeurs au projet Qt pour discuter de son avenir. L’un des principaux sujets de discussion a été la prochaine version majeure de Qt 6, la prochaine occasion pour casser la compatibilité du code existant et donc de revisiter certains choix de conception qui ne seraient plus adaptés au développement moderne (ce qui inclut également la liste des fonctionnalités désapprouvées lors de la vie de Qt 5).


Le premier et principal changement prévu concerne la version de C++ : actuellement, seul C++11 est autorisé, tant pour développer Qt que dans son interface (aux débuts de Qt 5, c’était encore C++98…). Qt 6 se baserait exclusivement sur C++17 (puisque la norme C++20 ne serait probablement pas finalisée à temps).

Qt 6 n’arrivera pas de sitôt : il faudra au moins attendre après Qt 5.14 (au moins dix-huit mois), c’est-à-dire en 2020.

Les développeurs gardent en tête les problèmes de portage causés par le passé, afin de minimiser l’impact pour ceux qui devront mettre à jour leur version de Qt. Certaines API pourraient cependant changer pour devenir plus faciles d’utilisation — quitte à perdre légèrement en performance — : pour les utilisateurs, il est plus profitable d’avoir un outil facile à utiliser que plus performant, puisque les applications arriveront plus vite aux utilisateurs (et probablement avec moins de défauts).

La compatibilité binaire sera aussi probablement cassée, afin de réduire la consommation de mémoire et d’implémenter certains algorithmes plus efficacement.

Plus dans le détail, quelques modifications déjà prévues :

• côté accessibilité : pour le moment, toute l’accessibilité (pour décrire l’interface de l’application à des outils comme des synthétiseurs vocaux) se base sur une copie de la hiérarchie des widgets et des composants. Cette manière de procéder est assez coûteuse en ressources et fragile (au moindre écart entre les hiérarchies, l’application peut planter). L’idée serait de fusionner l’interface d’accessibilité avec les widgets, de telle sorte que la hiérarchie ne soit plus dupliquée. Les données correspondant à l’accessibilité ne seraient allouées en mémoire que lorsqu’elles sont requises, ce qui reviendrait à une surcharge en mémoire d’un pointeur dans le cas de base ;
• côté Qt WebEngine : le code entre l’implémentation à base de widgets et pour Qt Quick présente une certaine quantité de doublons, qui devrait être limitée. Le démarrage et l’arrêt du moteur Web sont actuellement décrits comme des hacks, leur implémentation devrait être améliorée. Plus important, l’API de QWebEnginePage devrait être retravaillée : il ne devrait pas être nécessaire de créer des classes dérivées aussi souvent. QWebEngineCallback devrait disparaître au profit de la bibliothèque standard : std::function. Toutes les classes pourraient finir dans un espace de noms QtWebEngine, au lieu d’avoir un préfixe à rallonge (QWebEngine) ;
• côté Qt Widgets : certaines parties de l’API ont été placées dans Qt Widgets au lieu du module plus général Qt GUI avec la modularisation de Qt 5, mais leur place est probablement dans Qt GUI. Il s’agirait de QFileSystemModel (un modèle dont les données proviennent d’un système de fichiers) et des fonctionnalités d’annulation-restauration des actions. De même, la classe QSvgWidget aurait plus sa place dans le module Qt SVG ;
• côté Qt UI Tools : ce module de chargement dynamique d’interfaces (similaire à Qt Designer) a toujours fonctionné comme une bibliothèque statique. Cependant, cette manière de procéder a un impact sur la licence : le module était sous licence BSD ou commerciale. Avec Qt 6, il devrait être possible de l’utiliser comme une bibliothèque partagée : il passera alors sous la même licence que le reste de Qt (LGPL ou commerciale) ;
• côté style : le même code pourrait être utilisé pour les widgets et Qt Quick, à condition de retirer les dépendances trop fortes envers les widgets ;
• côté Qt Quick : le moteur de rendu et le graphe de scène pourraient voir de grands changements arriver. L’objectif changera légèrement : le moteur actuel est orienté vers les applications 2D, mais s’ouvrira à l’intégration avec des moteurs 3D (comme Unity), de réalité virtuelle ou augmentée. Qt Quick servirait alors uniquement à la partie interface en 2D, avec l’affichage réalisé dans une texture réutilisée par une autre application. Les changements seraient assez profonds, mais simples : QQuickScene serait le point d’entrée, au lieu de QQuickWindow, qui ne serait dès lors plus nécessaire pour une application Qt Quick. Plus d’API de rendu seraient gérées : OpenGL et le rendu logiciel seront toujours gardés, mais complétés par Direct3D 12, Vulkan et d’autres.
  
  
  

Voir aussi : la liste des changements déjà proposés pour Qt 6.
Source : Qt Contributors’ Summit 2018 wrap-up.