Six ans déjà que Qt 4.0 est sorti, en juin 2005. Depuis lors, beaucoup de choses ont changé dans l’industrie du logiciel : le développement se déroulait principalement pour le desktop, alors que les périphériques mobiles se sont répandus. L’interface utilisateur est passée de la souris au toucher, du statique au fluide. Sept versions mineures depuis cette époque ont permis à Qt de s’approcher des demandes actuelles, avec la sortie de Qt Quick par exemple. La base d’utilisateurs de Qt ne cessant de croître, il faut toujours rester proche des besoins nouveaux des développeurs.
Ainsi, pour rester à la pointe de la technologie et un framework leader dans l’industrie en général, Qt doit continuer à se renouveler. Qt 4 a été une évolution, les prochaines versions de Qt devront être dans sa perspective technique. Ces dernières années, de nouvelles fondations ont été esquissées pour la prochaine génération : Qt Quick, QML Scenegraph, Lighthouse, Qt WebKit.
En plus de son orientation vers l’open gouvernance, voici quelques pistes architecturales pour Qt 5.
Objectifs pour Qt 5
Mieux utiliser le GPU, pour obtenir des applications graphiques fluides et performantes, même avec peu de ressources.
Rendre la création d’applications avancées plus facile et plus rapide, avec QML et JavaScript.
Faire en sorte que les applications connectées au Web soient aussi puissantes que possible, notamment au niveau de l’insertion de contenu Web dans des applications Qt.
Réduire la quantité de code requise et sa complexité pour implémenter et maintenir un port.
Qt 4.7 contient encore du vieux code qui empêche certaines évolutions et Qt d’être aussi bon que possible pour la création d’applications next-gen. La plupart du code convient encore, alors que certaines parties bloquent le chemin de Qt 4.x.
Faciliter la migration entre Qt 4 et Qt 5
Avec Qt 5, il est prévu d’effectuer des changements bien précis dans les API pour abandonner certaines limitations du passé. La difficulté du portage de Qt 3 vers Qt 4 ne sera pas réitérée : la compatibilité des sources sera conservée pour la majorité des cas, alors que, à d’autres endroits, il sera nécessaire de la briser.
Il est actuellement envisagé de se focaliser sur un petit ensemble de systèmes supportés (Wayland, X11 pour Linux, en plus de Mac OS X et de Windows), le nombre total de plateformes supportées dépendra de l’activité de la communauté, suivant le principe de l’open gouvernance. Les autres systèmes d’exploitation ne seront pas maintenus par Nokia (principalement les UNIX commerciaux). Le but de Qt 5 est de fournir les meilleures fonctionnalités sur chaque plateforme, ce qui implique que l’on va d’abord fournir des fonctionnalités plus différenciées entre les OS, tout en offrant une réutilisation du code aussi efficace que possible pour la majorité des plateformes.
Développé ouvertement
Le modèle de développement va complètement changer entre Qt 4 et Qt 5, changement qui se profile depuis déjà longtemps : Qt 4 a principalement été développé par Trolltech puis Nokia, le fruit de ce travail a été publié. Qt 5 se veut développé par la communauté, un projet open source dès le tout début. Il n’y aura pas de différences entre un développeur de chez Nokia et un contributeur externe.
Vision
Qt 5 devrait être la fondation d’une nouvelle manière de développer des applications. En offrant toute la puissance de Qt en C++ natif, le focus sera déplacé vers un modèle, où le C++ est principalement utilisé pour implémenter les fonctionnalités derrière Qt Quick. Qt 5 mettra Qt Quick au centre, sans se couper du code déjà existant, il s’agira plus d’une restructuration. Les applications Qt/C++ traditionnelles vont continuer à fonctionner avec Qt 5, même si quelques changements vont être apportés sur les fondements de la manière de développer des applications.
On devrait s’attendre à ce que toutes les IU soient écrites en QML. JavaScript deviendra un citoyen de première classe de l’environnement Qt : beaucoup de logique, voire toute une application sera écrite en JavaScript, non en C++. Le but est que les développeurs commencent d’abord avec QML et JavaScript pour n’implémenter des fonctionnalités en C++ que lorsque cela est nécessaire. Dans ce cas, toute la puissance des API C++ pourra être utilisée pour implémenter des fonctionnalités plus complexes ou dont l’exécution doit être très rapide.
Le modèle basé sur QWidget sera conservé, les API liées aussi, pour la compatibilité, mais le long terme devrait voir QML comme le futur des interfaces utilisateur pour desktop. La solution retenue sera probablement des composants basés sur QML qui s’intègrent dans le style natif des plateformes desktop.
Les quatre grands changements architecturaux
Les premiers changements sont déjà en cours depuis un certain temps, le travail débute pour le reste. La plupart de ces changements pourraient être effectués avant août.
Changer l’architecture de la pile graphique
Qt Quick et QML Scenegraph seront au centre de la nouvelle architecture. QPainter sera toujours disponible et est très utile pour bien des choses, mais il ne sera plus utilisé pour l’interface principale. Qt aura besoin d’OpenGL (ES) 2.0 pour fonctionner. Les QWidget seront rendus par-dessus le graphe de scène, pas l’inverse comme actuellement.
Qt Components et Qt Mobility feront donc partie intégrante de Qt, plus des modules avec un statut spécial.
Baser tous les ports de Qt sur Lighthouse
Le projet Lighthouse a été lancé pour fournir une meilleure manière d’abstraire l’intégration au système de fenêtrage que ce qui est actuellement disponible. La maturité est proche avec Qt 4.8, son utilisation sera probablement requise pour Qt 5.0.
Utiliser une structure de répertoires modulaire
Beaucoup a déjà été fait ces dernières semaines, le travail est d’ores et déjà visible dans les nouveaux dépôts : http://qt.gitorious.org/qt. Cette modularisation va permettre de faciliter et d’accélérer l’intégration de contributions à Qt.
Séparer les fonctionnalités liées à QWidget dans une bibliothèque distincte
Les classes basées sur QWidget sont actuellement très importantes ; le modèle va cependant changer et les IU seront principalement faites avec QML. Séparer les fonctionnalités basées sur QWidget est donc une manière d’obtenir une architecture propre dans Qt 5.
Beta fin 2011, version finale en 2012
On ne doit pas trop changer dans les fondations de Qt, on veut aussi rendre facile le portage d’applications vers Qt 5 : on ne peut donc pas trop modifier la base de code déjà en place. Beaucoup des changements proposés se basent sur la modularisation de Qt, avec chaque bibliothèque partagée dans son propre répertoire. On devra supprimer quelques API rarement utilisées si elles se révèlent contraignantes à maintenir sans empêcher d’avancer. Du code en version beta devrait être disponible fin 2011, avec une version finale pour 2012.
Merci à Jacques Thery pour sa relecture !
