QtCon, première journée

Nouveautés pour macOS, analyse des performances et futur de Qt, un compte-rendu d'Arnold Dumas

La QtCon se déroule au Berlin Congress Center à Berlin et remplace en quelque sorte les Qt Developer Days, tout en fédérant d'autres communautés comme VLC, FSFE ou encore KDE. Les sessions sont pour la plupart techniques et touchent à différents aspects de Qt, de son développement à son utilisation. J'ai pour ma part assisté à quelques conférences, pour lesquelles je vous propose un compte-rendu.

« Qt on OS X » par Morten Sørvig

Une présentation qui se trouvait en fait être une sorte d'atelier où différents employés de la Qt Company étaient présents. Différents aspects relatifs à macOS y sont discutés.

Samuel Gaist a proposé deux séries de patchs sur Gerrit, afin d’implémenter un système de notification sous macOS. Cela pourrait devenir un module à part entière si d’autres systèmes d’exploitation venaient à être supportés.

Le 32 bits devrait être abandonné. Le seul cas pour lequel le 32 bits est encore nécessaire est lorsqu'il faut lier à des bibliothèques non disponibles en 64 bits.

Une nouvelle API est disponible sous macOS >= 10.9. Celle-ci devrait permettre d’améliorer l'espace et l’alignement entre les composants de l'interface graphique. Typiquement, toutes les valeurs actuellement en dur dans le code pour macOS devraient pouvoir être remplacées par des appels à cette nouvelle API.

Il a aussi été évoqué l’intégration du composant natif NSPopOver

« Linux perf for Qt developers » par Milian Wolff



Présentation de l’outil perf du noyau Linux dans un contexte de développement d’une application reposant sur Qt pour une carte ARM. Les versions que l'on peut obtenir depuis le gestionnaire de paquets sont souvent obsolètes. Il a donc été conseillé de compiler soi-même perf pour pouvoir disposer des dernières fonctionnalités et corrections de bogues.

Milian Wollf maintient une branche personnelle du noyau Linux avec des patchs pour perf qui ne sont pas encore disponibles dans la branche officielle : www.github.com/milianw/linux.git

En tant que débutant avec perf, on peut rencontrer plusieurs obstacles :

• des problèmes de permissions. Il existe un script Bash qui s’assure que les différents dossiers ont les bons droits pour que tout se passe correctement ;
• la variable CC doit uniquement contenir le nom du compilateur, en aucun cas des chemins vers quelque en-tête que ce soit. Par ailleurs, clang ne fonctionne pas ;
• il faut utiliser EXTRA_CFLAGS, CFLAGS est apparemment ignoré.

QTestLib propose un support basique de perf, le nombre d’itérations à effectuer peut être donné en argument :
Par défaut, l’interface textuelle de perf est loin d’être optimale, certaines informations sont redondantes, alors que d’autres, pourtant très utiles au développeur, manquent :
flamegraph.pl permet de générer un fichier SVG, ce qui permet de visualiser facilement les endroits lents ou peu performants du code.

Le profilage des applications QML est un peu plus complexe à cause du JIT qui empêche de remonter les appels. Cependant, avec le LBR (Last Branch Record), ce problème peut être partiellement contourné. Avec une variable d’environnement, ce problème peut être résolu.


« Qt 3D Basics » par Kevin Ottens

Présentation de Qt 3D : ce n’est pas conçu comme un moteur de jeu, même si cela est totalement possible en pratique. Conçu pour intégrer du contenu 3D dans des applications reposant sur Qt, en permettant d’afficher des composants de GUI (boutons, champs de texte). Quelques explications sur l’architecture du code, qu’est-ce que le pattern ECS (Entity Component System), quels sont ses avantages dans le cadre d’un tel projet.

Quelques démonstrations reposant sur l’interface QML, un donut que l’on peut manipuler avec la souris, un cube que l’on peut faire tourner et grossir, puis des exemples plus complexes, qui faisant partie du matériel de formation de KDAB, ne seront vraisemblablement pas disponibles.



Qt 3D peut aussi être utilisé pour effectuer des simulations physiques.

Les API C++ et QML sont identiques, chaque classe C++ QMaClasse est disponible sous le nom MaClasse en QML.

Puis les nouveautés à venir :




« Qt Project Status » par Lars Knoll

Rappel des progrès accomplis depuis la sortie de Qt 5.0, une nouvelle version tous les 6 mois en moyenne. Explication sur le changement de licence. Le nombre de rapports de défauts ouverts avec une priorité P0, P1 et P2 (c'est-à-dire des problèmes relativement critiques qui touchent un grand nombre d'utilisateurs) augmente, les développeurs font face à une charge de travail très importante.

Présentation de COIN et de RTA (Release Test Automation), respectivement le système d’intégration continue et le système de tests des installeurs générés par le premier. Les besoins en ressources augmentent constamment au fil des nouvelles versions, avec toujours plus d'OS à supporter. La version supportée à long terme 5.6 n’arrange rien à cette situation.

Présentation de Qt Lite, beaucoup de clients ont besoin d'une base plus légère, avec seulement un sous-ensemble des fonctionnalités du framework.

Qu’en est-il de Qt 6 ? Pas avant 2019, mais sûrement plus tard. Qt 6 devrait reposer sur C++17, conserver une grande compatibilité au niveau des sources avec Qt 5.X. Par ailleurs, la dernière version de Qt 5.X devra être supportée à long terme. Dans 5.9, Python devrait faire son retour. Pour 5.10, devrait faire la part belle au « cloud » et aux services connectés, sans que rien de concret ne soit annoncé. Cette version devrait aussi être l’occasion de corriger de nombreux détails et d’améliorer l’expérience développeur.



Ensuite, Lars Knoll a présenté les objectifs à long terme de Qt, module par module :

• Qt Core : alléger, alléger, alléger... Certaines fonctionnalités devraient être déplacées dans d’autres modules. Par ailleurs, le Meta Type System et le Moc devraient occuper les développeurs, ce dernier pouvant être plus rapide qu’il ne l’est actuellement ;
• QtN etwork : détection des appareils et/ou services, zeroconf a été évoqué ;
• Qt GUI/QPA : réduire la dépendance à OpenGL, support d’autres API graphiques comme Direct3D 12 ou Vulkan, OpenGL streaming, support de l’affichage à distance (Remote Display Support), support de Wayland pour le bureau Linux ;
• QML : possible intégration de fonctionnalités issues d’ECMAScript6, évaluation paresseuse des liaisons, compilation en avance (en cours avec 5.8 et la mise en cache), amélioration du ramasse-miettes  ;
• Qt Quick : nouveau système de gestion des événements (déjà en place dans 5.8), stabiliser et optimiser l'existant, hypothétique support de Vulkan et de la 3D sans dépendre de Qt 3D.

Au niveau de l’outillage, cela tournait beaucoup autour de clang, tant pour compiler que pour analyser le code. La distribution de clang dans les installeurs pour Windows a été évoquée, cela permettrait d’avoir un seul compilateur pour les différentes plates-formes. Le support de CMake doit par ailleurs être amélioré.

Le support de Python va devenir officiel, mais il reste encore beaucoup à faire. Shiboken, l’outil qui permet de générer le code Python de lien avec l'implémentation C++, a du mal à gérer la base de code qui contient de plus en plus de C++11, c'est dans ce contexte que fut évoqué clang pour l'analyse de code. PySide devient un projet à part entière du Qt Project avec le Desktop en ligne de mire. Les systèmes mobiles pourraient être supportés, mais ce n’est pas à l’ordre du jour.

Systèmes d’exploitation et compilateurs supportés :

• Win8/WinRT ne devraient plus être gérés à partir de 5.9, même si ce n’est pas officiel ;
• VS13 devrait aussi être abandonné avec 5.10 (présenté comme le pire compilateur actuellement supporté par Qt).