En QML, une erreur des plus fréquentes concerne la syntaxe des fichiers QML et JavaScript — y compris dans des applications en production, principalement pour des composants chargés de manière asynchrone. La plupart de ces erreurs ne sont que des typos, mais elles restent fort ennuyantes et facilement évitables.

Pour éviter ce genre d’erreurs, Qt 5.4 proposera un outil en ligne de commande pour vérifier la syntaxe des fichiers QML. Il est prévu notamment pour s’intégrer facilement aux outils d’intégration continue, tout comme xmllint et json_verify sont utilisés pour les fichiers XML et JSON, respectivement :

Cet outil ne fait que de la vérification syntaxique, pas sémantique : en cas d’erreur dans un nom de variable, par exemple, l’outil sera incapable de le détecter. La vérification de ce genre d’erreur est bien plus difficile, car la sémantique dépend également du contexte de l’application en cours d’exécution.

Source : KDAB contributions to Qt 5.4: qmllint

Le processus de peaufinage de Qt 5.4 est entamé avec la sortie de la première préversion, Qt 5.4 Alpha. Aucune nouvelle fonctionnalité ne devrait arriver d’ici à la version finale, juste des corrections de défauts. Cette version apporte son lot de nouveautés, avec un grand nombre de fonctionnalités mais également la finalisation du port vers Windows RT.

Plateformes mobiles

Après moult tests, la préversion du port pour Windows RT arrivée avec Qt 5.2, fin 2013, est devenue mature. Pour Windows Phone, seule la version 8.1 sera supportée : cette décision a été prise pour éliminer la dépendance envers le compilateur D3D, ce qui facilite le déploiement. La plupart des modules sont maintenant disponibles, il devient donc très facile de porter une application Qt vers Windows Phone, les tablettes sous Windows RT mais également vers l’interface moderne de Windows 8 – y compris la mise à disposition sur le Windows Store.

Sur Android, les applications Qt Quick auront un style natif par défaut – précédemment, il était nécessaire d’utiliser Ministro (une installation globale de Qt pour Android, au lieu de fournir le cadriciel sous forme de bibliothèques pour chaque application).

Également, le module Qt Bluetooth pourra utiliser Bluez5, une implémentation de la pile de protocoles Bluetooth pour Linux. Également, ce module dispose d’une préversion du standard Bluetooth Low Energy (aussi dit LE ou Smart), qui devrait diminuer considérablement la consommation d’énergie lors de communications Bluetooth.

Amélioration de la gestion d’OpenGL

Qt 5.3 apportait QQuickWidget, une classe facilitant l’introduction de contenu Qt Quick dans une application traditionnelle, par là facilitant l’adoption des interfaces déclaratives en QML. Qt 5.4 amène QOpenGLWidget, qui ambitionne de faire la même chose avec le contenu OpenGL, en remplacement de la vieillissante classe QGLWidget. Par conséquent, le module Qt OpenGL est déprécié : toutes ses fonctionnalités sont reprises à d’autres endroits.

Une nouvelle API fait d’ailleurs son apparition, QQuickRenderControl, grâce à laquelle le rendu de scènes Qt Quick 2 dans des tampons OpenGL sera plus efficace. Ces images pourront alors être utilisées ailleurs, dans du code utilisant Qt ou totalement dissocié. QOpenGLContext fait le lien avec des contextes OpenGL, ce qui facilite l’utilisation du contenu Qt dans d’autres moteurs de rendu.

Sous Windows, il est désormais possible de choisir d’utiliser directement l’implémentation d’OpenGL fournie (souvent par le pilote graphique) soit ANGLE (une implémentation d’OpenGL par-dessus DirectX). Avant, il était nécessaire de compiler plusieurs fois Qt pour choisir son implémentation – plusieurs téléchargements sont d’ailleurs disponibles pour une même version de Qt, ce qui brouille les pistes pour les débutants.

Contenu Web

La plus grande nouveauté de Qt 5.4 est le module Qt WebEngine, qui intègre Chromium dans Qt (le moteur de rendu Web utilisé par Chrome, notamment). L’API proposée est voulue facile à utiliser mais toujours facilement extensible. L’intégration à la pile graphique a notamment été particulièrement travaillée, les textures de Chromium étant directement affichées dans le graphe de scène OpenGL de Qt Quick. Ce module est désormais disponible pour Windows, Linux et OS X, en plus des plateformes embarquées.

Le module Qt WebKit continue à être distribué avec Qt 5.4, mais ne verra plus de nouvelles fonctionnalités arriver : les défauts seront toujours corrigés, mais il est envisagé de le déprécier dans les versions à venir, puisque ses fonctionnalités sont reprises et augmentées par Qt WebEngine.

Un deuxième nouveau module fait son apparition : Qt WebChannel propose d’intégrer le code C++ et QML avec des applications Web en HTML et JavaScript, en exposant des fonctionnalités du modèle de métaobjets QObject au code JavaScript exécuté par Qt WebEngine ou Qt WebKit. Il s’agissait d’une limitation des versions précédentes de Qt WebEngine par rapport à Qt WebKit.

Divers

Qt Location, apparu avec Qt Mobility 1.0 il y a quelques années, suit son cours, mais n’est pas encore prêt pour Qt 5.4. Le même sort atteint Qt 3D, également annoncé depuis longtemps et souvent repoussé.

Cette nouvelle version de Qt vient également avec une nouvelle licence, la LGPL 3, mais également le souhait d’unifier l’écosystème entre versions libres et commerciales.

Source : Qt 5.4 Alpha Available

Les bibliothèques KDE, utilisées pour construire les applications KDE, se modernisent avec la sortie de KDE Frameworks 5.0 début juillet et 5.1 début août. La principale différence par rapport à KDE Platform 4/kdelibs est la modularisation : les composants sont désormais découplés, les dépendances réduites au maximum, de telle sorte qu’il n’est plus nécessaire de lancer une artillerie KDE complète pour lancer une application qui en utilise seulement une fraction. La première version proposait déjà une cinquantaine de composants, apportant des fonctionnalités bienvenues et manquantes dans Qt (bien qu’une partie a déjà été intégrée dans Qt 5), avec très peu de dépendances en dehors de Qt lui-même ; KDE Frameworks 5.1 porte le compte à une soixantaine. L’objectif est de ne plus faire de différence entre une application Qt et une application KDE.

Organisation des dépendances

Les modules des KDE Frameworks 5 se divisent en trois catégories, selon leurs dépendances à l’exécution :

• les éléments fonctionnels n’ont aucune dépendance ;
• les éléments d’intégration peuvent avoir des dépendances afin d’intégrer les éléments fonctionnels au système d’exploitation ou à la plateforme ;
• les solutions, par contre, sont libres au niveau des dépendances.

De même, ils se répartissent en trois niveaux (tiers) selon leurs dépendances lors de la compilation : au premier niveau, les seules dépendances autorisées sont Qt et d’autres bibliothèques externes à KDE et à Qt ; au deuxième niveau, les modules ne peuvent dépendre que du premier niveau ; au troisième niveau, les dépendances peuvent être enregistrées envers tous les niveaux.

Ces deux hiérarchies ne sont pas orthogonales : une solution de troisième niveau peut dépendre d’autres solutions d’autres niveaux.

Fonctionnalités

Les modules fonctionnels proposent une série de fonctionnalités bien utiles à un grand nombre d’applications, comme :

• KArchive gère les techniques de compression les plus populaires, comme ZIP, 7-Zip, TAR ou XZ : il peut compresser et décompresser tant des flux de données (GZip, BZip2, XZ) que des archives proprement dites (7Zip, Ar, TAR, ZIP) ;
• KPlotting propose des fonctionnalités simples pour l’affichage de graphiques, en ce compris l’anticrénelage ou la superposition (en quelque sorte, il s’agit d’une version simplifiée de Qwt) ;
• Threadweaver facilite l’écriture de code multifil grâce à la notion de travaux (jobs), avec une gestion des dépendances et une intégration au système de signaux et de slots de Qt ;
• KConfig s’occupe de la configuration des applications, avec une génération de code pour la lecture et l’écriture de ces fichiers, mais également le lien entre les fichiers de configuration et l’interface graphique pour changer les paramètres.

Côté intégration, Sonnet fait le lien avec la correction orthographique (tant aspell, hspell, hunspell qu’enchant) et Solid fournit un accès aux données issues directement du matériel (niveau de batterie, état du réseau, etc.). Dans ce dernier cas, pour certaines fonctionnalités, certaines dépendances à l’exécution sont requises. KI18n intègre GNU gettext, une bibliothèque pour la gestion des traductions ; ce module facilite le travail avec d’autres flux de traduction, plus souvent basés sur gettext.

Jusqu’à présent, ces fonctionnalités sont du premier niveau. Au troisième, pour les solution, KIO propose une interface d’édition de fichiers identique, qu’ils soient stockés en local ou en distant. KService propose des fonctionnalités avancées de gestion des extensions, comme leur localisation sur le système de fichiers.

Sources

Frameworks 5 (dont l’image), First release of KDE Frameworks 5, Second release of KDE Frameworks 5

Après trois années de développement, l’idée d’Inqlude, soit un dépôt de bibliothèques, un gestionnaire de paquets centré sur Qt, arrive à un certain niveau de maturité : l’auteur considère le projet comme prêt pour les utilisateurs précoces. Notamment, l’outil est utilisé pour générer le site Web inqlude.org ; parmi les bibliothèques présentes, un grand nombre provient des KDE Frameworks 5. À terme, il se veut l’équivalent de Bower ou npm en JavaScript, de RubyGems ou encore de pip pour Python.

Les métadonnées sont gérées, comme d’autres avant lui, par des fichiers de manifeste, écrits en JSON. La gestion du téléchargement et de l’installation des paquets n’est pas encore prête : une implémentation simple est d’ores et déjà disponible, mais il manque encore des métadonnées pour rendre le processus utile.

Les prochaines versions sont déjà planifiées :

• 0.8 : la documentation sera améliorée pour faciliter les contributions ;
• 0.9 : les fichiers de manifeste ne pourront plus changer de structure
• 1.0 : l’outil pourra gérer des paquets en local, ce qui le rendra effectivement utile pour les utilisateurs et développeurs d’applications Qt.

En l’état, le projet permet déjà d’avoir un aperçu de l’écosystème Qt, des diverses bibliothèques non inclues dans la distribution officielle de Qt mais néanmoins utiles.

Source : Announcing first Inqlude alpha release

Depuis les débuts de Qt, il y a une vingtaine d’années, l’édition libre existe. Elle fut d’abord limitée aux plateformes UNIX et X11, puis s’est progressivement ouverte, notamment pour Windows et divers systèmes embarqués. De même, la licence a évolué : depuis une licence non standard, de plus en plus libre avec les versions (qui se souvient de la QPL ?), Qt 4 est passé à la GPL 2, ce qui a eu pour effet d’éliminer les conflits juridiques qui empêchaient d’utiliser Qt dans une application GPL, avec une mise à jour vers la GPL 3 dès sa diffusion par la FSF. L’une des principales fonctionnalités de ces licences est d’imposer que les logiciels dérivés (soit tout utilisateur) publient leur code source sous la même licence (« licence virale »). En 2009, Qt 4.5 devient disponible sous la LGPL 2.1 : la licence commerciale n’est plus requise pour un développement fermé, la LGPL n’impose plus la licence sur les produits dérivés.

Cependant, cette version de la LGPL n’est pas parfaite : on peut lui reprocher de n’être pas assez claire au sujet des modifications de la bibliothèque, Qt en l’occurrence. Ainsi, bien qu’en violation totale de l’esprit de la licence, certains constructeurs interdisent l’installation de versions modifiées de la bibliothèque sur leurs appareils. La FSF a corrigé cette faille dans la LGPL 3, qui formalise de manière juridique l’intention première, ce qui protège mieux la liberté des utilisateurs. C’est pour cette raison que Digia proposera Qt 5.4 également sous licence LGPL 3, en plus de la LGPL 2.1 et de la licence commerciale.

Nouveaux modules

Cependant, certains modules de Qt ne seront disponibles qu’en LGPL 3 et sous une licence commerciale, comme le nouveau Qt WebEngine (pour l’édition libre). D’autres nouveaux modules pourront être libérés (alors que Digia ne les prévoyait que dans l’édition commerciale !), comme Qt Canvas3D (support complet de WebGL à l’intérieur de Qt Quick) ou Qt WebView (intégration assez légère du moteur de rendu Web natif dans Qt, actuellement uniquement pour Android). De même, le style Android pour les Qt Quick Controls sera disponible : il posait problème avec la LGPL 2, puisqu’il utilise des composants sous licence Apache 2.0, une licence incompatible, mais pourra être intégré grâce à la LPGL 3.

Impact sur les utilisateurs de Qt

Tous ceux qui utilisaient Qt sous la licence GPL 3 n’auront aucun souci à se faire, étant donné la compatibilité avec la LGPL 3. Tous les modules de Qt 5.3 seront toujours disponibles sous LGPL 2.1, ce qui ne posera aucun problème. Par contre, si vous mettez à jour vers Qt 5.4 et utilisez l’un des nouveaux modules disponibles uniquement en LGPL 3, vous devrez vous plier aux exigences de la nouvelle version.

Impact sur KDE

Lors du lancement du projet KDE, un environnement de bureau libre entièrement basé sur Qt, un accord juridique a été établi entre Trolltech (qui développait Qt) et KDE e.V. (l’entité légale derrière KDE), afin de s’assurer que Qt reste toujours disponible sous une licence libre : l’idée est que, si le projet quittait la scène du libre, le code puisse toujours évoluer, sans remettre en question KDE (cette utilisation d’une bibliothèque pas entièrement libre a été un frein à son adoption à la fin des années 1990). Cet accord est géré par la KDE Free Qt Foundation, administrée tant par KDE e.V. que par Digia.

Ce changement de licence est une occasion d’améliorer le contrat liant ces deux entités. Notamment, toutes les plateformes, mobiles ou non, y sont intégrées (soit Windows, OS X, iOS, Windows RT, actuellement). Également, la fondation reçoit les droits sur toutes les contributions au Qt Project.

Voir aussi les textes de licence : GPL 3, LGPL 3.

Sources : Adding LGPL v3 to Qt, Protecting Software Freedom – the Qt License Update

Les dernières années furent relativement mouvementées pour Qt : le passage de Trolltech à Nokia, la création du Qt Project, puis le passage de Nokia à Digia, bientôt la création d’une société indépendante de Digia (mais toujours entièrement contrôlée par Digia) qui s’occupera exclusivement de Qt. Les objectifs de Trolltech et Digia sont fort similaires : Qt est un produit qu’ils vendent, les revenus servant à développer l’outil, à l’améliorer, le résultat étant visible tant dans l’édition gratuite (open source) que commerciale. D’ailleurs, actuellement, les trois quarts des modifications du code proviennent d’employés de Digia ; en plus de gérer une grande partie de l’infrastructure hébergeant le projet, Digia est donc la première société à contribuer au projet Qt.

Cependant, les versions commerciale et libre ont commencé à diverger : outre le fait que l’édition payante offre, en sus du support, une série de bibliothèques (Qt Quick Entreprise Controls, Charts, Qt Quick Compiler, etc.) et est adaptée aux plateformes embarquées (QNX, VxWorks, etc.), les installeurs et même les sites Web sont différents (http://qt.digia.com/ pour l’édition commerciale, https://qt-project.org/ pour le libre). Par conséquent, ces deux éditions entrent en compétition directe l’une avec l’autre, se présentant comme des produits opposés, avec des difficultés pour passer d’une édition à l’autre.

Pour réduire cette fracture, Digia s’apprête à créer une nouvelle société, dont le seul objet sera le développement de Qt. Elle sera cependant entièrement administrée par Digia. En même temps, le site Web côté Digia pour Qt sera retiré, au profit d’un site unique pour les deux éditions, qui donnera alors une vue plus large de l’écosystème Qt, en comparant les éditions libre et payante. Également, les paquets d’installation seront rationalisés, avec un seul installateur pour les deux éditions : la migration d’une édition à l’autre sera plus simple, tout en réduisant la charge de travail lors de chaque version. L’objectif est de fournir des paquets mieux testés et donc de meilleure qualité (il ne faudra plus tester les deux séparément).

Le plan a d’ores et déjà été discuté lors du Qt Contributor Summit, qui s’est déroulé en juin dernier à Berlin, avec les principaux contributeurs : les premiers éléments devraient être visibles avec la sortie de Qt 5.4. L’inconvénient, déjà reporté par la communauté, serait une plus grande difficulté de distinguer le contenu réservé à l’édition commerciale, payante.

Sources : Defragmenting Qt and Uniting Our Ecosystem, Digia to Streamline its Organizational Structure

Qt est un framework C++ relativement ancien. Pour supporter des fonctionnalités intéressantes (gestion des signaux et slots, métaobjets, introspection, etc.) sur un grand nombre de compilateurs pas forcément très au courant des standards C++, il a dû développer un outil de génération de code, le moc (metaobject compiler).

Il donc n’est pas suffisant de compiler les fichiers source d’une application et de les lier avec le framework, puisqu’il faut générer du code. Ce simple oubli a déjà causé bien des pertes de temps, même pour des développeurs plus chevronnés. Les outils de compilation s’y sont habitués (QMake, CMake et d’autres), les EDI également… mais pas forcément les utilisateurs : il est la cause d’un certain nombre de grandes incompréhensions de la part de débutants avec le framework. Les plus puristes n’apprécient pas non plus cette partie hors standard de la chaîne de compilation.

Plus techniquement, moc est un outil en ligne de commande qui prend en entrée un fichier source de l’application avec des macros particulières (la plus connue étant Q_OBJECT) et génère un autre fichier source à ajouter à la compilation. Ce dernier implémente les métaobjets grâce aux informations récoltées par ces macros particulières. Pour cette étape de génération, moc utilise un analyseur assez naïf qui se limite à l’extraction des informations nécessaires à son bon fonctionnement, il achoppe donc sur du code C++ plus avancé ou sur les nouveautés de C++11/14.

Clang

Une première expérience était de remplacer l’étape du moc externe au compilateur par une extension de ce compilateur, afin de générer le code nécessaire à la volée. moc-ng s’occupe de cette partie, avec un plug-in pour Clang (un compilateur C++), mais aussi un outil en ligne de commande équivalent au moc mais utilisant Clang pour l’analyse du code source de l’application (et évite donc les écueils de la solution actuelle).

Clang est bien connu pour ses messages d’erreur, bien plus explicites que ceux d’autres compilateurs. Proposer le moc en tant qu’extension permet de générer des messages d’erreur en cas de mauvaise utilisation des commandes du générateur, notamment en cas de typo. Le message généré par le moc actuel est très suboptimal :

Grâce aux fonctionnalités plus avancées de Clang pour la recherche dans les fichiers source, l’extension propose même la correction de la typo à l’origine de l’erreur :

Bien qu’il ne s’agisse que d’une expérience, d’une preuve de faisabilité, cette réimplémentation fonctionne bien : elle peut remplacer le moc pour la compilation d’une grande partie de Qt, les tests n’échouant pas plus souvent qu’avec le moc officiel.

Se passer du moc

Boost implémente déjà les concepts de signaux et slots sans utiliser de précompilateur dans Boost.Signals2. Le moc propose également des fonctionnalités d’introspection et de réflexion, c’est à ce moment que le comité de standardisation du C++ entre en jeu : le document N3814 est une demande de propositions pour la réflexion à la compilation. Cette fonctionnalité sera intégrée au plus tôt dans C++17 et aucune version n’est actuellement implémentée dans un compilateur.

La proposition N3951 donne de nouvelles significations aux mots clés typedef et typename, de telle sorte que le code

deviendrait équivalent à

Ainsi, un compilateur implémentant cette fonctionnalité pourrait générer l’équivalent du QMetaObject actuel à l’aide de quelques traits, sans outil extérieur. Pour le moment, il est possible d’expérimenter cette fonctionnalité en réécrivant soi-même les typedef… et typename… dans le prototype, avec le grand avantage de garder la compatibilité binaire avec le code généré par le moc : les structures générées donnent tous les slots, les signaux et les propriétés requises pour la construction du métaobjet à l’exécution. Pour distinguer les signaux et slots, C++11 propose des attributs, mais il serait plus agréable de les placer au niveau des spécifications d’accès de groupe (soit une extension du document N3955) :

Sources : Proof Of Concept: Re-implementing Qt moc using libclang et Can Qt’s moc be replaced by C++ reflection?

Voir aussi :

• de QObject aux métaobjets, une plongée au cÅ“ur des fondations de Qt, un article de Louis du Verdier ;
• classes de traits et de politiques en C++, un tutoriel d’Alp Mestan.

Qt Creator 3.1 est désormais disponible en préversion, peu après Qt 5.2. Parmi les nouveautés, le moteur d’analyse du C++ interne peut être remplacé par Clang : l’avantage principal est que Clang est bien plus précis sur la sémantique du C++ que le moteur interne, mais au prix de performances bien moindres (ce qui a d’ailleurs ralenti fortement le développement de cette fonctionnalité, en cours de développement depuis 2011).

Pour rappel, Clang est un compilateur C++ basé sur LLVM, une architecture de compilateurs libre notamment développée par Apple et désormais utilisée sur un certain nombre de BSD. Il supporte une série de langages proches de C++, comme C ou Objective-C. Il s’agit également du premier compilateur libre à supporter complètement le standard C++14, notamment avant GCC.

Outils de développement

Cette fonctionnalité est activable à la demande, comme un plug-in (ClangCodeModel). Les binaires proposent cette fonctionnalité, mais elle n’est pas (encore) activée par défaut. La différence principale à ce niveau sera pour ceux qui compilent eux-mêmes Qt Creator : il faudra disposer de libclang (détails dans les sources).

Autre changement au niveau des outils de développement, toute version de GDB sans script Python est désormais dépréciée (la dernière plateforme pour laquelle une telle version de GDB n’est pas disponible est OS X, mais LLDB le remplace avantageusement, surtout avec le support de fonctionnalités autrefois réservées à GDB). Le profileur QML a été aux petits oignons, avec un grand nombre de bogues corrigés.

Un autre plug-in expérimental fait son apparition : Beautifier, pour reformater du code. Il peut utiliser les outils externes Artistic Style, Clang-format et Uncrustify.

Support de Windows RT

La dernière préversion de Qt 5 propose un support expérimental de Windows RT, Qt Creator se met au diapason avec un nouveau plug-in (encore expérimental, comme le support de WinRT dans Qt) pour supporter cette plateforme. Tout ne fonctionne pas encore, mais il est déjà utilisable. Parmi les fonctionnalités qui fonctionnent déjà bien :

• enregistrement du Windows Runtime et de Qt pour Windows Phone ;
• support de Windows Runtime et des Windows Phone Kit ;
• compilation d’applications pour Windows Runtime et Windows Phone ;
• lancement d’applications par un bouton depuis l’EDI.

Pour le moment, cependant, le débogage n’est pas encore fonctionnel, le bouton est d’ailleurs grisé dans l’interface.

Plus en détail, pour gérer le déploiement et le lancement d’applications, le plug-in utilise deux nouveaux outils en ligne de commande, windeployqt et winrtrunner, proposés par Qt 5.3. En tant que plug-in expérimental, le support de Windows RT n’est pas activé par défaut.

Sources : Qt Creator 3.1 beta released et Experimental Version of Qt Creator’s WinRT Plugin