Nouveauté de Qt 5.5 : Canvas3D, une API 3D bas niveau compatible avec WebGL pour Qt Quick

Avec Qt 5.5, le module Canvas3D sort de sa période d’incubation. Il se propose comme un équivalent à WebGL à l’intérieur de Qt Quick (donc accessible en JavaScript depuis une interface QML), en tant qu’API 3D de bas niveau inspirée d’OpenGL. L’objectif est de faciliter le portage d’applications depuis WebGL vers Qt Quick — voire de partager du code entre les deux.

La compatibilité avec WebGL n’est pas encore parfaite, la différence principale étant que WebGL est défini pour des pages HTML. Les écarts par rapport à la norme sont corrigés au fur et à mesure de leur détection ; la conformité complète ne sera pas forcément atteinte, à cause de la forte dépendance de WebGL envers le modèle de données de HTML, inexistant dans Qt Quick. Ceci n’empêche pas le portage facile ou le partage de code entre des applications WebGL-HTML et Qt Quick.

En même temps, l’API de Canvas3D s’inspire fortement de QOpenGLWidget, la manière actuellement conseillée d’intégrer de la 3D dans des applications Qt en C++. Par exemple, le code suivant peint l’écran avec une couleur aléatoire.

import QtCanvas3D 1.0
 
Canvas3D {
    id: canvas3d
    anchors.fill: parent
    focus: true
    property var gl
 
    onInitializeGL: {
        gl = canvas3d.getContext("experimental-webgl");
 
        // Setup clear color to be a random color
        gl.clearColor(Math.random(), Math.random(), Math.random(), 1.0);
 
        // Setup viewport
        gl.viewport(0, 0, canvas3d.width * canvas3d.devicePixelRatio, canvas3d.height * canvas3d.devicePixelRatio);
    }
 
    onPaintGL: {
        // Clear background to current clear color
        gl.clear(gl.COLOR_BUFFER_BIT);
    }
 
    onResizeGL: {
        var pixelRatio = canvas3d.devicePixelRatio;
        canvas3d.pixelSize = Qt.size(canvas3d.width * pixelRatio, canvas3d.height * pixelRatio);
        if (gl)
            gl.viewport(0, 0, canvas3d.width * canvas3d.devicePixelRatio, canvas3d.height * canvas3d.devicePixelRatio);
    }
}

Tout comme WebGL, Canvas3D est de très bas niveau. Pour débuter, il peut être préférable d’utiliser une couche d’abstraction comme three.js : la version WebGL a été portée vers Canvas3D, avec une série d’exemples et d’utilitaires couramment utilisés. Par exemple, une application 3D de visualisation d’une voiture a pu être portée de WebGL vers Canvas3D en quelques jours.

Ce nouveau module arrive en même temps que les premières préversions de Qt 3D 2.0. Ces deux modules, bien qu’ils aient le même objectif — ajouter du contenu 3D dans une application Qt Quick —, recouvrent des besoins différents : Qt Canvas3D est une API de bas niveau, tandis que Qt 3D est beaucoup plus proche du moteur 3D, avec un graphe de trame complet (une description orientée données de la scène et des transformations à y appliquer lors du rendu). Qt Canvas3D n’est pas accessible en C++, puisque ces fonctionnalités sont d’ores et déjà accessibles par QOpenGLWidget (qui facilite l’utilisation directe d’OpenGL), contrairement à Qt 3D.

Source : Introducing Qt Canvas3D

Qt 5.5 RC et plans pour les prochaines versions

La version RC vient de sortir, corrigeant uniquement des défauts par rapport aux préversions précédentes. L’objectif actuel est d’avoir une version finale le premier juillet (avec un retard de plusieurs mois sur les plans).

Qt 5.6 devrait être la dernière compatible avec une série de combinaisons de plateformes et de compilateurs : plus de GC 4.6, d’OS X 10.7, de Windows Embedded Compact 7, de QNX 6.5 — Qt 5.7 devrait faire le ménage dans sa compatibilité, pour ne garder que les versions les plus récentes, ce qui ira de pair avec une migration complète vers C++11 (le code n’aura plus l’obligation de compiler en mode C++98). Cette version 5.6 aura cependant un support à long terme de deux ans pour tous ceux qui ne peuvent pas encore effectuer de migration, tandis que la 5.7 laissera plus de temps pour modifier le code plus en profondeur.

Cependant, les modules Qt Quick 1 et Qt WebKit ne seront plus inclus dans les binaires distribués, la relève étant déjà assurée (Qt Quick 2 et Qt WebEngine, même si ce dernier n’est pas exempt de débats). Qt Script devrait faire ses adieux avec Qt 5.7.

Sources : [Development] QtCS: Long Term Release discussion, [Development] Qt LTS & C++11 plans

L’avenir de Qt 4.8 passe-t-il par CopperSpice ?

La dernière version de maintenance de Qt 4.8 est sortie, numérotée 4.8.7. Qt 5.0.0 est sorti fin 2012 ; l’un des objectifs était de garder une grande rétrocompatibilité avec les versions précédentes, pour faciliter la transition.

Cependant, certains développeurs ont préféré effectuer des changements plus profonds dans Qt 4.8, notamment afin d’exploiter les templates C++ et les nouveautés de la norme C++11. Leur travail a donné naissance à CopperSpice, dérivé de Qt 4.8. L’un des points essentiels est la disparition du moc, le compilateur de métaobjets utilisé par Qt depuis ses débuts. Ce générateur de code servait, dans les années 1990, à pallier les manques du C++ à l’époque, qui rendait impossible l’implémentation de systèmes comme les signaux et slots (également implémentés dans Boost.Signals dès le début des années 2000, sans tel outil).

Ce n’est pas la première fois que l’obsolescence de cet outil était pointée du doigt, malgré les justifications apportées dans la documentation. L’un des défauts couramment rapportés est l’impossibilité d’utiliser les templates avec ce système de métaobjets, mais également la performance (comparaisons de chaînes de caractères à l’exécution) — CopperSpice cite d’ailleurs dans sa documentation une liste d’inconvénients. Récemment, des preuves de concept ou des réflexions avancées ont été proposées pour s’en passer ou l’inclure au niveau du compilateur.

CopperSpice se défait donc complètement de cet héritage du passé, remplacé par C++11. Par conséquent, du code utilisant CopperSpice n’a pas besoin d’outil externe pour sa compilation, ce qui pouvait rendre les choses plus compliquées pour l’intégration avec du code C++ existant ; le code C++ utilisant Qt peut être transformé à l’aide d’un outil automatique de traduction, baptisé PepperMill. Il intègre également des nouveautés de Qt 5. De même, la compilation se fait avec les GNU AutoTools, certes plus répandus que qmake, mais pas forcément plus modernes (contrairement à CMake, par exemple). L’un des objectifs à plus long terme est de remplacer les conteneurs de Qt par leurs équivalents de la STL (ce qui évite de les recoder).

Cette manière de procéder pose cependant question : était-il nécessaire de créer un nouveau projet pour « juste » se débarrasser du moc, c’est-à-dire s’écarter d’une grande communauté ? Pourquoi repartir d’une version aussi ancienne (Qt 4.8.2 date de mai 2012), alors que Qt 5 a justement permis beaucoup de nettoyage ? Les développeurs de CopperSpice ont aussi leur propre version de Doxygen pour la documentation (renommée DoxyPress). L’univers Qt Quick ne fait pas partie des fonctionnalités de CopperSpice.

Sources : annonce de CopperSpice, site officiel, discussion sur Phoronix.

Qt WebEngine : le problématique empaquetage de KDE

Qt 5.4 est venu avec une énorme nouveauté, Qt WebEngine, une intégration de Chromium (le projet libre derrière Google Chrome) pour l’intégration de contenu Web dans des applications Qt. Chromium est un véritable navigateur, avec notamment une pile réseau complète, construit sur Blink, un moteur de rendu dérivé de WebKit. L’objectif est de déprécier Qt WebKit assez rapidement.

Ce nouveau module est d’ores et déjà utilisé par certaines parties de KDE 5, comme KDE PIM, un outil de gestion des informations personnelles.

Avis des mainteneurs

Pourtant, ce mouvement ne se fait pas sans à-coup, notamment du côté des mainteneurs de KDE pour Debian et Fedora, par la voix de Lisandro Pérez Meyer. Leur grief est que Qt WebEngine est un composant logiciel très difficile à empaqueter, notamment à cause de ses nombreuses dépendances. En elles-mêmes, elles ne posent pas de problème ; cependant, Qt WebEngine les intègre dans ses sources avec des modifications, ce qui empêche d’utiliser les versions installées à l’échelle du système. Cette manière de procéder consomme plus d’espace disque et plus de mémoire, mais aussi complique la tâche lors de mises à jour de sécurité (chaque binaire doit alors être mis à jour séparément, plutôt que la copie globale).

Cette difficulté est déjà présente au niveau de Chromium et explique à elle seule pourquoi ce navigateur n’est pas inclus dans Fedora. En plus, le moteur JavaScript V8 manque de portabilité : WebKit contenait une couche d’abstraction du moteur JavaScript, que Blink (donc Chromium) a abandonné, ce qui force l’utilisation de V8. Pour Fedora, le problème est mineur, puisque V8 est compatible avec toutes les plateformes majeures visées par la distribution ; par contre, des outils comme Qt Assistant, s’ils passaient sur Qt WebEngine, ne pourraient plus fonctionner sur les plateformes secondaires (comme ARM 64 bits — dite AAarch64 —, PowerPC ou s390 — utilisée par les IBM System z).

De plus, la compilation des informations de débogage est pratiquement impossible, à cause de la quantité astronomique de RAM utilisée par l’éditeur de liens (plus de huit gigaoctets) — en augmentation depuis Qt WebKit, qui n’était déjà pas connu pour sa facilité de compilation.

Réponse des développeurs

La réponse que font les développeurs de KDE aux mainteneurs des distributions n’implique pas de grands changements du côté du développement de Qt WebKit ou de Chromium : selon Albert Astals, l’objectif d’une distribution est de fournir les logiciels demandés aux utilisateurs ; si leurs règles ne leur permettent pas de distribuer ces logiciels, c’est qu’il faut adapter les règles.

Au contraire, Franz Fellner propose d’adapter les applications : pourquoi forcer l’utilisation d’un moteur aussi complexe que Chromium quand les besoins sont relativement limités, comme afficher des courriers électroniques ?

D’autres avis sont encore plus tranchés, comme celui de Kevin Kofler : puisque Chromium n’en a cure de l’empaquetage, il faudra que Qt en maintienne sa propre version… ou déprécier le module Qt WebEngine au profit de Qt WebKit !

Sources : Distros and QtWebEngine (discussion), Deprecating modules with 5.5 (message de Kevin Kofler)

Compatibilité avec Windows 10

L’actualité Windows est actuellement trépidante, les détails sur la nouvelle version du système d’exploitation arrivant régulièrement, en prévision d’une sortie officielle cet été. Quel degré de compatibilité Qt propose-t-il avec cette nouvelle version ? Toutes les applications Qt qui fonctionnaient sur les versions précédentes de Windows continueront à tourner, sans limitation, qu’il s’agit d’applications traditionnelles (Win32) ou modernes (WinRT, Windows Store).

Par contre, ces applications pourraient présenter des dysfonctionnements par rapport aux nouvelles fonctionnalités, comme le mode fenêtré des applications modernes (elles ne sont plus limitées au plein écran) : les versions actuelles de Qt présentent quelques défauts lors du redimensionnement, qui seront corrigés avec Qt 5.5 ; également, le style n’est pas automatiquement adapté à WinRT. Qt est d’ores et déjà testé avec les préversions de Visual Studio 2015, même si le support officiel ne sera disponible qu’à sa version finale (Qt 5.5 devrait être disponible avant Windows 10 et Visual Studio 2015).

Comme toujours avec Qt, le même code pourra être utilisé pour plusieurs déploiements d’une même application : le même code pourra servir pour OS X, Linux, Windows, mais également pour WinRT.

Une nouveauté non technique du port de Qt 5.5 vers WinRT sera la licence, comme pour de précédents modules : il s’agira d’une double licence LGPL 3-GPL 2+ (en plus d’une licence commerciale), compatible avec les termes et conditions de déploiement sur le Windows Store.

Source : Windows 10 Support in Qt

Sortie de qbs 1.4.0

qbs est un système de compilation prévu pour remplacer qmake pour les projets Qt. La description des projets se fait en QML. L’outil est certes prévu pour Qt, mais a une vocation plus généraliste : il peut être utilisé pour tout type de projet C++ (comme qmake).

La version 1.4.0 vient avec quelques nouveautés intéressantes, comme l’ajout de projets Android : qbs est maintenant capable de compiler des projets pour Android, qu’ils contiennent du code natif ou non (tant avec le SDK que le NDK, donc) ; cette fonctionnalité n’a pour le moment rien de spécifique à Qt et n’est pas intégrée à Qt Creator.

Un module d’archivage fait son apparition, afin de générer des fichiers compressés après la compilation à partir d’une liste de fichiers à inclure. La propriété builtByDefault permet d’indiquer qu’un produit ne doit pas être compilé, à moins d’être explicitement demandé ; elle sert notamment à lancer des séries de test, comme la cible check de nombreux Makefile.

Source : qbs 1.4.0 released

Qt Creator 3.4.0

La nouvelle version de Qt Creator, numérotée 3.4.0, vient d’arriver. Elle se focalise sur le peaufinage de l’existant, avec des corrections de défauts (notamment au niveau du débogueur) et des améliorations du code interne, tout en apportant quelques nouvelles fonctionnalités.

Côté C++, une nouvelle action de refactorisation a été ajoutée pour déplacer les définitions de fonction en dehors d’une définition de classe ; également, l’autocomplétion propose maintenant la nouvelle syntaxe pour la connexion entre signaux et slots arrivée avec Qt 5. Un nouveau filtre propose également de signaler tous les fichiers C et C++ inclus dans le projet, même sans être explicitement mentionnés.

L’intégration Android est désormais compatible avec les chaînes de compilation 64 bits. Le développement sur des plateformes embarqués sans Qt (bare metal) peut être fait avec des projets génériques.

Clang se fait une place plus importante dans l’EDI : son analyseur statique n’est plus considéré comme expérimental, il peut d’ailleurs être utilisé en combinaison avec les compilateurs Visual C++ et MinGW.

Sources : Qt Creator 3.4.0 released, Qt Creator 3.4 RC1 released, Qt Creator 3.4 beta1 released.
Voir aussi : les notes de version.

PhysX sur GitHub : quelques nouveautés

Quelques nouveautés du côté de PhysX et de l’ouverture de son code (sans qu’on puisse parler de logiciel libre, toutefois). Le premier élément tient plus de l’ordre du détail : le dépôt GitHub précédent est déprécié au profit d’un dépôt par version majeure. PhysX-3.3 ne contiendra donc que PhysX 3.3 (et les diverses mises à jour, probablement), un nouveau dépôt sera créé pour la branche 3.4.

Ce nouveau dépôt contient maintenant les sources nécessaires à la compilation de PhysX pour iOS, ainsi que celles des exemples livrés avec le SDK. Plus intéressant : dans les semaines à venir, NVIDIDA proposera un contrat de licence pour les contributeurs. En conséquence, les développeurs de PhysX pourront recevoir et accepter des pull requests de la part d’utilisateurs de PhysX, ce qui ouvre le développement du moteur à un public plus large, tout comme Unreal Engine 4.

Source : New Github Repo: PhysX-3.3. Old repo PhysX is deprecated!

Qt Installer Framework 2.0

Le Qt Installer Framework est une brique logicielle prévue pour créer des installateurs, tant en ligne que hors ligne, pour Windows, Linux et OS X, en gérant les mises à jour. Bien que focalisé sur Qt, l’outil est suffisamment générique pour des applications ne l’utilisant pas.

La version 2.0 vient de sortir, avec quelques nouvelles fonctionnalités. La raison principale pour le changement de version majeure est que cet outil est maintenant compilé avec Qt 5 plutôt que Qt 4. La compatibilité a été préservée par rapport à la version précédente : il devrait être possible de mettre à jour une installation réalisée avec QIF 1.6 avec un installateur basé sur cette nouvelle version.

Notamment, le moteur JavaScript précédemment utilisé, Qt Script, a été remplacé par celui de Qt Quick, en gardant la compatibilité avec les scripts existants. Aussi, il devient possible de lancer des installations sans aucune interface graphique.

Télécharger Qt Installer Framework 2.0.
Voir aussi : les notes de version.
Source : Qt Installer Framework 2.0 Released

Aperçu des nouvelles fonctionnalités prévues pour Qt 5.5

Bien que la liste ne soit pas complètement figée, Qt 5.5 devrait venir avec une série de nouvelles fonctionnalités. La principale est l’ajout du module Qt 3D, sans être finalisé (technology preview), un ambitieux projet remontant à l’époque Qt Mobility et Qt 4.8, qui facilite l’intégration de contenu 3D dans des applications Qt, tout en gardant des API C++ et Qt Quick. Il s’agit d’un moteur de rendu 3D prévu pour l’extensibilité : son architecture devrait s’accommoder de tout besoin au niveau du rendu de scènes 3D.

Un autre morceau de Qt Mobility, Qt Location, fait son retour dans Qt 5. Là où Qt Positionning fournit la position de l’utilisateur, Qt Location en facilitera l’exploitation, comme la gestion des itinéraires, la navigation, la recherche de lieux, etc.

L’édition commerciale fournit le module Qt Quick Entreprise Controls, avec des composants bien utiles comme des jauges (verticales ou circulaires), des cadrans, des indicateurs de statut ou encore des boutons à bascule. Toutes ces fonctionnalités (et d’autres encore, comme une vue en arbre) seront ajoutées au module Qt Quick Controls de l’édition libre, sous le nom de Qt Quick Extras.

Les amateurs de vidéos pourront se réjouir de la gestion de GStreamer 1.0 : jusqu’à présent, seules les versions 0.10 étaient prises en charge (plus aucune mise à jour n’a été réalisée depuis 2012). Ainsi, le décodage de vidéos pourra être accéléré sur le GPU, par exemple. Ces améliorations de performances n’ont pu se faire que par des modifications importantes au niveau de la structure du code de GStreamer, causant des difficultés pour la mise à jour côté Qt. Cependant, la version utilisée par défaut lors de la compilation est toujours la 0.10.

D’autres modules devraient être dépréciés, comme Qt WebKit (en cours de remplacement par Qt WebEngine), Qt Declarative (remplacé par Qt Quick 2) et Qt Script (remplacé par le moteur de script de Qt Quick2 ). Ils pourraient ne plus être inclus dans les paquets binaires dès Qt 5.6.

Comme pour Qt 5.4, ces nouveaux modules sont disponibles sous les licences GPL2 et LGPL3, en plus d’une offre commerciale.

Sources : Licensing of new modules in Qt 5.5, Qt3D: wip/newapi branch is dead. Long live dev!, Qt 5.5 Is Packing On New Features, Going Into Feature Freeze Soon, What is new in Qt 5.5, Deprecating modules with 5.5.