Un point sur le futur de Qt après le Qt World Summit

Après une conférence Qt World Summit à Berlin très enrichissante en rencontres et en découvertes, il est temps de faire le point.

Des Keynotes rythmées aux sessions techniques, il s'est dit beaucoup de chose en ce début de novembre à Berlin. Aujourd'hui on va se concentrer sur la keynote de Lars Knoll, CTO de The Qt Company, avec comme sujet l'avenir de Qt.

Un bilan sur Qt 5

7 ans après la sortie de Qt 5.0, il est l'heure pour Qt de faire un peu de ménage et de solidifier ses bases pour le futur.

Les débuts de Qt 5 ont servi à prouver que Qt était toujours viable en temps que framework crossplatform. La solution en a profité pour sortir du triptyque Linux, macOS et Windows pour s'étendre vers l'embarqué et le mobile. Les ajouts de fonctionnalités ont étés nombreux et les valeurs fondatrices de Qt encore et toujours affirmées (Cross-platform, flexibilité, facilité d'utilisation, API ainsi qu'outils et documentation hors-pair, maintenabilité, stabilité, compatibilité, ...).

La dernière version de Qt 5, la 5.15, est prévue d'être publiée en mai 2020. Cette version sera une version LTS (Long Term Supported), supportée pendant 3 ans après sa sortie.

‍

Une vision pour Qt 6

La prochaine version majeure de Qt, Qt 6, est attendue pour novembre 2020 (jusqu'à nouvel ordre). Qt étant un framework très stable et se souciant de la compatibilité binaire et de source, une augmentation de version majeure est l'opportunité de faire des changements plus radicaux pour partir sur des fondations fraiches et solides. Dans les grandes lignes, cela va permettre à Qt de s'adapter au monde qui avance autour de lui, de nettoyer et ré-architecturer le cœur de Qt et de se préparer pour les années à venir.

L'embarqué avec les micro-controlleurs et l'automobile était clairement à l'honneur dans les allées du Qt World Summit. Il ne faut pas se le cacher, ce sont sur ces plateformes que la division commerciale de Qt veut mettre l'accent, chaque device donnant lieu à l'achat d'une license, à l'inverse des projets plus traditionnels sur desktop où la license est attachée au développeur et non pas au nombre de copies du logiciel vendues. C'est ce marché de l'embarqué que The Qt Company veut séduire avec Qt 6 (et avec Qt for MCUs en avant-première).

Les cibles desktops et mobiles ne seront pour le moins pas oubliées car même si elles ne rapportent pas forcément autant directement, elles apportent beaucoup de visibilité au projet et aident Qt à se faire une place dans le paysage compétitif des frameworks d'UI (même si Qt ne se limite pas qu'à de l'UI).

‍

Un peu de ménage

Pour préparer la venue de Qt 6, on commence par faire place nette en supprimant les modules, classes et méthodes dépréciés en Qt 5.

Les modules supprimés seront :

• Qt Script
• Qt Canvas 3D
• Qt Quick Controls 1
• Qt Quick 1

Certaines classes pourraient continuer d'exister dans un module de compatibilité (mais rien n'est encore acté) :

• QRegExp -> Qt5::QRegExp (remplacé par QRegularExpression)
• QList -> Qt5::QList (Le QList de Qt 6 sera surement un alias vers QVector)

‍

De l'ouverture d'esprit

Pour des nouvelles bases solides, Qt s'ouvre vers l'extérieur et adopte CMake comme système de build. Il y'a beaucoup de détracteur de CMake dans le monde Qt mais ça n'en reste pas moins le choix le plus utilisé dans le monde du C++. D'aucuns auraient préféré QBS avec une approche plus novatrice et n'étant pas un nième générateur de Makefile, mais le projet n'a pas eu l'inertie et le soutien nécessaire pour devenir assez mature. Beaucoup de freins à l'adoption de CMake dans Qt ont déja été résolus ou sont en projet, les développeurs de Kitware (créateurs de CMake) sont moteurs et n'hésitent pas à collaborer avec des développeurs du monde Qt pour faire avancer ça intelligemment. Le support de CMake dans Qt Creator s'améliore aussi de release en release. QMake sera toujours supporté mais ne sera plus l'outil de build conseillé.

Le C++ a beaucoup évolué ces dernières années grâce à l'impulsion donnée par le C++11 pour en arriver au C++17 aujourd'hui et avec le C++20 qui pointe le bout de son nez. Toujours dans une optique de s'adapter à un écosystème C++ maintenant plus dynamique que jamais, Qt 6 nécessitera un compilateur compatible C++17. Malheureusement, il faudra vraisemblablement attendre Qt 7 pour que celui-ci s'appuie sur C++20 et ses changements majeurs. L'adoption du C++17 se fera surtout en interne, notamment avec l'utilisation des fold expressions ou de if constexpr pour faciliter l'implémentation de certaines fonctions. Ne vous attendez pas à voir des std::optional ou std::string_view dans une API Qt, cela provoquerait trop d'incompatibilité au niveau du code source.

‍

Les conteneurs de Qt

Qt a longtemps fourni ses propres conteneurs, mais la rapide évolution du C++ et la grande disponibilité de la librairie standard aujourd'hui enlève des arguments à cette politique.

Les conteneurs Qt accusent un certain retard sur quelques fonctionnalités (toujours pas d'<span class="css-span">emplace_back</span> sur QVector et cie.) ou ont des implémentations malheureuses (performance de <span class="css-span">QList</span>, taille limité à la valeur max de <span class="css-span">int</span>, ambiguïté <span class="css-span">QMap/QMultiMap</span>). L'arrivée de std::ranges pour C++20 est un autre motivateur pour se tourner vers un C++ plus idiomatique.

Plusieurs conteneurs Qt vont devenir de simples wrappers autour de conteneurs de la bibliothèque standard, comme <span class="css-span">QPair</span> ou <span class="css-span">QMap</span>. Cela permettra d'alléger la charge de maintenance tout en gardant l'API intuitive et habituelle de Qt et en gagnant potentiellement en performance. <span class="css-span">QList</span> deviendra un synonyme de <span class="css-span">QVector</span>, cette unification sera pratiquement 100% compatible au niveau du code source, simplifiera grandement les APIs Qt (une classe de moins à se soucier) et améliorera les performances dans la plupart des cas.

Nouveau système de propriétés C++

Les property bindings de QML ont fait des jaloux dans le monde Qt C++, un nouveau système de propriétés arrivent pour régler ça. A nous le code C++ plus déclaratif et fini les <span class="css-span">connect</span> à répétitions.

Aujourd'hui en QML on peut faire ça :

<pre><code>Item {
   property int width
   property int height: width
   property int border: width / 10
}</code></pre>

Cela a pour effet de lier ("binder"), les propriétés <span class="css-span">height</span> et <span class="css-span">border</span> à la propriété <span class="css-span">width</span> de l'objet. À chaque fois que <span class="css-span">width</span> change, les 2 autres seront réévaluées.

Avec Qt 6, on pourra créer des property bindings en C++ directement. Un code C++ équivalent au code QML précédent pourrait ressembler à ça :

<pre><code>struct Item {
   Property<int> width;
   Property<int> height;
   Property<int> border;

   Item() {
       height.bind(width);
       border.bind([this]() {
           return width / 10;
       });
   }
}</code></pre>
‍

QML 3

Des grands bouleversements sont à venir pour le langage QML. Dans les grandes lignes, le langage deviendra plus strict au profit de plus de performance et il s'appuiera sur le nouveau système de propriétés vu plus haut. À noter qu'il sera toujours possible d'utiliser du code QML 2, plus permissif, dans Qt 6. Ce langage me tenant à cœur, nous y reviendrons plus en profondeur dans une prochaine publication.

‍

Nouvelle architecture graphique

Dans Qt 5, la technologie graphique utilisée était principalement OpenGL, mais de l'eau a coulé sous les ponts depuis. L'arrivée de Vulkan comme successeur d'OpenGL sur Linux, l'abandon d'OpenGl au profit de Metal côté Apple et le DirectX 12 sur Windows oblige Qt à revoir sa copie. Pour s'adapter à ces nouvelles solutions, Qt mise sur une nouvelle couche d'abstraction maison, Qt RHI (Rendering Hardware Interface). Les appels à <span class="css-span">QPainter</span>, le scenegraph Qt Quick ou Qt 3D passeront tous par Qt RHI pour être traduit et passé au système graphique hôte sous-jacent.

‍

Se préparer à Qt 6

Qt voulant garder son image de framework stable, un effort sera fait pour minimiser le plus possible les soucis de compatibilité entre Qt 5 et Qt 6. Pour nous faciliter la tâche de portage de code Qt 5 à Qt 6 sur le code amené à changer, des warnings seront ajoutés sur les parties de code susceptibles d'être dépréciées. Un certain nombre de nouvelles fonctionnalités Qt 6 seront disponibles dès Qt 5.15 pour les essayer (et les adopter ?) en avance. Si vous n'utilisez pas encore clazy, ça sera l'occasion de l'intégrer à votre routine de développement. Cet analyseur de code statique basé sur clang (au même titre que clang-tidy) spécifique à Qt proposera des diagnostics et des suggestions pour moderniser votre code et le préparer en douceur au passage à Qt 6.

Pour les curieux

Si vous voulez continuer votre découverte de ce que nous réserve Qt 6 et voir ce qui se passe dans les coulisses, je vous invite à surveiller la mailing list Development (beaucoup d'activité dernièrement suite au Qt Contributors Summit fin Novembre) et le bugtracker de Qt (ce bug est un bon point de départ).

Sources :

• Technical vision for Qt 6 - The next big release, Lars Knoll
• Towards Qt 6, Lars Knoll

‍