Le paquet Qt Mobility 1.1.0 est désormais disponible en beta ! Il fournit tout un set de nouvelles API, de grandes améliorations des API existantes ainsi que le support de nouvelles plateformes. Parmi les nouvelles API, nous pouvons compter Organizer, Versit/Organizer, Document Gallery et Feedback. Du côté des améliorations, l’API Location a été étendue avec les fonctionnalités si bien nommées Maps, Navigation et Landmarks ; l’API Multimedia a reçu des fonctionnalités de Camera. En images, la démo Mapviewer sur plusieurs plateformes :

De plus, des bindings QML sont disponibles, ce qui ne laisse présager que le meilleur tant pour les développeurs que les designers d’interfaces ! Des interfaces animées, riches, puissantes et mobiles développées en un rien de temps, une technologie apparue avec Qt 4.7.

Au niveau du support des plateformes mobiles, MeeGo, le nouvel OS développé par Intel et Nokia, est également supporté, partiellement pour le moment. Cependant, faisant partie du tier 1 des plateformes supportées, ces manques vont bientôt être comblés ; l’objectif est que MeeGo devienne la plateforme principale pour Qt Mobility.

Un changement très important est à noter pour cette version : l’API Telephony Events n’est plus et ne sera plus disponible dans Qt Mobility. Pourquoi ? Cette décision se base sur le constat que cette API n’apportait au final pas grand chose aux développeurs tiers. Elle avait été créée pour contrôler les événements de téléphonie du mobile ; cet utilisation est fort valable mais requiert beaucoup plus de recherche en termes d’événements et dans le domaine de la téléphonie pour voir comment répondre au mieux aux besoins des utilisateurs. Pendant cette phase de Technology Preview, nous avons remarqué que le peu de fonctionnalités dans une API aussi prometteuse ne pouvait que déconcerter les utilisateurs de cette API. Par conséquent, son développement a été arrêté.

Les bindings QML requièrent Qt 4.7, évidemment. Le paquet Qt Mobility 1.1 beta est disponible pour les plateformes Symbian en utilisant le paquet SIS pour Symbian. Il supporte aussi Maemo. Nous n’avons pas de nouvelle sur le firmware de Maemo 5 à communiquer pour le moment, nous vous tiendront au courant dès que nous aurons quelque chose.

Télécharger Qt Mobility 1.1.0 beta !

L’équipe de développement de Qt Mobility aimerait nous proposer ses avancées sur la version 1.2 – actuellement toujours en l’état de Technology Preview, rien n’est donc finalisé – ainsi que, comme cela était prévu pour la version 1.2, des paquets RPM pour tester sur MeeGo (en effet, l’objectif principal de cette version était le support de cette plateforme). Les sources sont aussi évidemment disponibles en paquets séparés, si vous souhaitez tester cette technology preview sous d’autres plateformes (pas de paquet disponible pour Symbian ou autre). Cette version de Qt Mobility requiert au moins Qt 4.7.0.

La version beta est prévue pour la dernière semaine de janvier 2011 ; ensuite, la version finale, pour début 2011 (pas plus de détails pour le moment). Maemo 5 ne sera pas supporté dans cette version officiellement, des paquets compilés par les communautés seront très vraisemblablement disponibles, cette distribution ayant fusionné avec Moblin d’Intel pour former MeeGo ; il sera donc normalement possible de mettre à jour tout système utilisant Maemo 5 et passer à MeeGo.

nt fusionné avec Moblin d’Intel pour former MeeGo ; il sera donc normalement possible de mettre à jour tout système utilisant Maemo 5 et passer à MeeGo.

Quelles sont les nouvelles fonctionnalités ?

Deux nouveautés sont à mettre sur le devant de la scène : les connectivités Bluetooth et NFC (Near Field Communication). Vous pouvez aussi consulter la roadmap complète. Quelques problèmes sont d’ores et déjà connus pour cette version.

Installation

Sous MeeGo, ces quelques commandes installeront la dernière version :

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 !

Qt 4.8 est maintenant disponible pour test et retours de la part de la communauté !

La version 4.8 de Qt va contenir beaucoup d’améliorations au niveau de la qualité du code et des performances, fruits des recherches de ces douze derniers mois, en bénéficie par exemple le système de fichiers. Il inclut aussi la couche d’abstraction de la plateforme Lighthouse, qui permet un portage de Qt sur d’autres systèmes graphiques plus simple pour des tiers. Autre changement important, les améliorations dans la gestion du réseau sur Symbian.

Les paquets disponibles actuellement ont été testés sur Windows 7, Mac OS X 10.6, Linux et Symbian^3. La liste des plateformes que supportera effectivement Qt 4.8 sera diffusée en temps et en heure. Une liste des fonctionnalités d’ores et déjà dépréciées est disponible.

La beta de Qt 4.8 devrait être disponible dans les prochaines semaines, la Release Candidate dans la seconde moitié de 2011. Elles ne seront disponibles que par l’intermédiaire du Qt SDK.

Les sources : http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.8.0-tp.tar.gz