Qt 6 en 2020 ?
Les premiers plans des développeurs sont d'ores et déjà dévoilés

Le , par dourouc05, Responsable Qt
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.


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de koala01 koala01 - Expert éminent sénior https://www.developpez.com
le 18/06/2018 à 0:40
Salut,

Il y a bien "longtemps" (c'était encore Qt-4.x ) j'avais proposé de rendre QMap plus "compatible" avec std::map, en rajoutant des paramètres template, parce que c'est template <Key, Value> QMap contre template <Key, Value, Comparator=less,Alloc = allocator<pair<const Key,T> >std::map.

Cela avait été refusé à l'époque parce que cela aurait cassé la compatibilité binaire, ce que j'avais très bien compris. Mais Qt5 n'est sorti que plusieurs années plus tard, et, comme je n'y faisais pas trop attention à l'époque, je n'ai pas pu profiter de l'occasion pour relancer l'idée.

Crois tu qu'il serait possible de la faire passer avec Qt-6
Avatar de dourouc05 dourouc05 - Responsable Qt https://www.developpez.com
le 18/06/2018 à 1:29
Très probablement, oui ! Tu profiterais aussi d'une ouverture plus directe aux nouvelles normes C++ et à la bibliothèque standard, ce qui était moins le cas avec Qt 5.
Avatar de Matthieu76 Matthieu76 - Membre confirmé https://www.developpez.com
le 18/06/2018 à 10:29
J'utilise beaucoup Qt mais je n'utilise que des fonctions simples, à part un peu d'interface du multi-threading, je n'utilise pas grand-chose de Qt. L'interface de mes programmes est utilise Qt mais le back-end n'utilise pas du tout Qt, ne le référence même pas.
À mon avis je ne verrais pas vraiment la différence entre QT 5 et Qt 6. Un QPushButton restera un QPushButton.
Avatar de koala01 koala01 - Expert éminent sénior https://www.developpez.com
le 18/06/2018 à 15:07
Citation Envoyé par dourouc05 Voir le message
Très probablement, oui ! Tu profiterais aussi d'une ouverture plus directe aux nouvelles normes C++ et à la bibliothèque standard, ce qui était moins le cas avec Qt 5.
J'ai donc introduit un rapport de bug pour lequel la réponse a été
Current thinking is to reimplement QMap and QHash with Standard Library containers. I don't know if we need to define a comparator template parameter, but it doesn't hurt to
J'ai fait valoir que, dans ce cas, rajouter un parametre template avec une valeur par défaut ne changerait pas grand chose pour l'implémenteur, mais pourrait changer énormément pour l'utilisateur

Et les grands esprits se rencontrent, car, même si je ne l'ai pas proposé, je m'étais fait la réflexion que la bibliothèque standard avait bien évolué depuis les débuts de Qt, et que, s'il était cohérent de fournir différents conteneurs "perso" à l'époque, la SL a prouvé sa stabilité depuis, si bien que partir sur quelque chose comme
Code : Sélectionner tout
1
2
3
4
template <typename Key, typename Value, typename Comp=less>
class QMap : private std::map<Key,Value,Comp>{
 
};
pour garder le nom du conteneur et pouvoir adapter les quelques fonctions qui divergent (en prenant / renvoyant un int au lieu d'un size_t) faciliterait la tâche
Avatar de Matthieu76 Matthieu76 - Membre confirmé https://www.developpez.com
le 19/06/2018 à 10:13
Citation Envoyé par koala01 Voir le message
renvoyant un int au lieu d'un size_t
Tiens d’ailleurs, pourquoi mon compilation me retourne un warning quand je compare un unsigned int à un size_t ?
Un size_t n'est pas simplement un #define d'un unsigned int ? Un size_t est bien définie sur 4 octets ?
Avatar de foetus foetus - Expert confirmé https://www.developpez.com
le 19/06/2018 à 12:29
Citation Envoyé par Matthieu76 Voir le message
À mon avis je ne verrais pas vraiment la différence entre QT 5 et Qt 6. Un QPushButton restera un QPushButton.
Et non Maintenant, on peut faire des connections/ signaux avec des fonctions anonymes.

Et j'ai lu sur les Internets , que Qt veut remplacer le moteur graphique "QGraphicsView/ QGraphicScene" par du QML/ Qt Quick.
Et là tu devras séparer la présentation (QML) du code logique (C++)

Citation Envoyé par Matthieu76 Voir le message
Un size_t n'est pas simplement un #define d'un unsigned int ?
Et non Sur des plateformes 64 bits, un type int a une taille de soit 4 soit 8 octets.
Et le type size_t doit avoir une taille de 8 octets [sur une plateforme 64 bits]*

Édit : * rajout suite au message ci-dessous de koala01 et effectivement le verbe devoir est trop fort
Avatar de koala01 koala01 - Expert éminent sénior https://www.developpez.com
le 19/06/2018 à 14:07
Citation Envoyé par foetus Voir le message
Et non Sur des plateformes 64 bits, un type int a une taille de soit 4 soit 8 octets.
Et le type size_t doit avoir une taille de 8 octets.
Il n'est mis nulle part qu'il doit avoir une taille de 8 octets...

D'ailleurs, à part char <= short, short <= int, int <= long et long <= long long, et CHAR_BITS pour définir le nombre de bits d'un char, aucune taille n'est donnée pour les différents types

Si tu veux travailler avec un type de taille précise, tu dois te tourner vers les alias de type intXX_t

Ce qui est dit, c'est qu'il doit avoir un nombre de byte "suffisant que pour permettre la représentation de n'importe quelle taille sur le système cible".

Ce doit être un type non signé, car une taille ne peut pas être négative, mais, selon le système cible (système d'exploitation, quantité de mémoire, ...), size_t peut être un alias de type sur unsigned short, unsigned int ou unsigned long long

Du coup, l'avertissement peut varier en fonction de la situation (et des réglages du compilateur):

S'il te parle simplement de comparaison entre une valeur signée et une valeur non signée, c'est que int et size_t font la même taille (mais l'un est signed et l'autre unsigned)
s'il te parle de "perte de précision" ou de "perte de valeur", c'est que l'un est plus petit que l'autre
Avatar de dourouc05 dourouc05 - Responsable Qt https://www.developpez.com
le 21/06/2018 à 15:51
Albert Astals Cid, un employé de KDAB (cette société étant l'une des plus grosses contributrices à Qt), donne sur son blog plus de détails sur les discussions qui ont eu lieu sur Qt 6. Tout d'abord, la date est bien confirmée pour novembre 2020. D'ici là, Qt 5 continuera à avoir ses versions mineures semestrielles, la dernière devant être Qt 5.15 (elle aura une maintenance à long terme).

D'un point de vue technique, Qt 6 s'appuiera sur C++17, pas une norme plus ancienne. La migration devrait être très facile, au moins pour ceux qui ont suivi les fonctionnalités désapprouvées au fil du temps. En peu de mots, Qt 6 ne devrait pas avoir de fonctionnalité majeure, plutôt ressembler à Qt 5.15 en enlevant toutes les fonctionnalités désapprouvées et en changeant les interfaces qui doivent l'être. Pour faciliter la migration, l'essentiel des problèmes de compatibilité entre Qt 5 et 6 devraient être des choses qui cassent clairement à la compilation (sans nécessiter trop de travail de réécriture, de préférence) : autant que possible, les changements de comportement à l'exécution seront évités.

Le système de compilation de Qt 6 n'est pas encore décidé, mais il est certain que ce ne sera plus qmake. Le choix semble assez limité, cependant : des gens travaillent sur Qbs (une petite étude a d'ailleurs été récemment lancée par le nouveau gestionnaire de produit), mais personne sur un autre candidat. CMake n'a pas été retenu, parce qu'il n'est pas compatible avec toutes les plateformes de Qt (pour l'embarqué, par exemple). Les fichiers de configuration nécessaires seront de toute façon inclus pour que l'on puisse compiler des applications Qt avec CMake.

Ainsi, l'objectif est de continuer à travailler normalement sur Qt 5 : toutes les fonctionnalités qui peuvent y être intégrées le seront, elles ne seront pas retardées pour faire de Qt 6 une version particulièrement impressionnante.
Avatar de Matthieu76 Matthieu76 - Membre confirmé https://www.developpez.com
le 21/06/2018 à 16:14
Citation Envoyé par dourouc05 Voir le message
Le système de compilation de Qt 6 n'est pas encore décidé, mais il est certain que ce ne sera plus qmake.
À mon avis je n'ai pas tout compris mais qmake ne fait pas que convertir les fichiers .pro en Makefile ? Et du coup, y aura-t-il aussi une nouvelle version de QtCreator ?
Avatar de LittleWhite LittleWhite - Responsable 2D/3D/Jeux https://www.developpez.com
le 21/06/2018 à 16:17
Bonjour,

Qt Creator est déjà compatible QBS.
De plus, dire que qmake ne fait "que" convertir en Makefile, c'est un peu restreint. Premièrement, il ne génère pas que des Makefile (on peut générer des fichiers pour XCode, des fichiers pour Visual Studio...). Ensuite, il supporte un pseudo langage permettant les conditions, la création de fonction et bien plus.
Responsable bénévole de la rubrique Qt : Thibaut Cuvelier -