Qt 5.0 est sorti. C'est une évolution majeure de l'une des bibliothèques C++ les plus utilisées et certainement celle qui couvre le plus de besoins.
Bien qu'étant une version majeure, elle ne casse pas aussi violemment la compatibilité que lors du passage de Qt3 à Qt4. La liste des améliorations et les changements en profondeur dans l'organisation de Qt5 rendent néanmoins pertinent ce changement de version.
Le projet libre le plus emblématique exploitant la puissance de Qt est KDE, mais bien d'autres applications l'utilisent, qu'elles soient libres (VLC, Scribus, Avidemux, etc.) ou propriétaires (Google Earth, Opera, la Freebox V6, Skype, etc.).
Merci à tous les contributeurs de cette dépêche : Nÿco, reno, Eric Bénard, ZeroHeure, Florent Zara, Philippe Fremy, olivierweb, detail_pratique, Raoul Volfoni, Laurent Pointal, Gof, baud123, ecyrbe, liberforce, Emmanuel C, Yves Bourguignon, tankey, Xavier Claude, Jean Gabes, Alexandre P, Arcaik, jeberger, Olivier, El Titi, Trollgouin, Benoît, RbN et jay.
Sommaire
- Qt, bien plus qu'une bibliothèque graphique
- Changement dans l'organisation
- Un développement ouvert
- Compatibilité source
- QPA par défaut
- Ajouts
- Et pour la suite
Qt, bien plus qu'une bibliothèque graphique
On ne le répètera jamais assez : Qt est bien plus qu'une simple bibliothèque graphique multiplateforme. Elle fournit :
- une abstraction de certains types et structures de données
- des composants graphiques
- l'accès et la manipulation de bases de données
- des moyens de communication via un réseau IP
- des fonctionnalités multimédia (audio, vidéo, caméra, microphone)
- la possibilité de lire et écrire du XML, du SVG, du JSON ou encore de manipuler et afficher du HTML
- l'affichage et l'écriture de fichiers graphiques et de documents au format ODF
- une gestion fine des traductions
- les signaux et slots qui sont une implémentation du patron de conception observateur
- etc.
L'aspect multiplateforme va au-delà du simple trio Windows, Mac OS X et Linux/X11 sur x86. Wayland – le nouveau protocole graphique visant à remplacer X11 – est géré, y compris sur ARMv7. Cela s'explique par une orientation vers le monde de l'embarqué qui s'est sérieusement accélérée depuis le rachat de Trolltech (l'entreprise à l'origine de Qt) par Nokia. Le support d'X11 est modifié pour passer d'Xlib à XCB.
Changement dans l'organisation
Depuis le 9 août 2012 Digia est propriétaire de l'ensemble de la bibliothèque. Digia est cette entreprise finlandaise qui disposait déjà du droit exclusif de vente de licence commerciale et qui s'occupait du support payant. À l'époque, Nokia était toujours le propriétaire de l'ensemble du code et choisissait son évolution. Pour rappel, Nokia a racheté Trolltech (le premier éditeur de Qt) en 2008 et a cédé la partie commerciale à Digia en 2011.
Digia a annoncé dans un communiqué de presse vouloir renforcer l'équipe de développement, afin de porter rapidement Qt sur Android, iOS et Windows 8 (la plateforme mobile), tout en précisant maintenir son attention sur la version Bureau. L'entreprise reprendrait 125 développeurs de l'équipe R&D que Nokia consacrait à Qt.
Le développement de la bibliothèque restera ouvert puisque « Digia encourage tous les membres de l'écosystème actuel à continuer à travailler à l'amélioration de Qt […] ». L'entreprise précise que le plan d'affaire à double licence sera préservé.
Du côté des autres acteurs économiques liés à Qt, on peut signaler la société Jolla, composée d'anciens du projet MeeGo de Nokia (cf. le nokia N9), qui a repris le flambeau de Qt embarqué sur smartphone et qui projette de sortir prochainement du matériel sous Sailfish OS (ex Meego/Mer avec une UI propriétaire en plus). Mais aussi RIM qui utilise Qt pour l'interface du futur blackberry 10.
Un développement ouvert
Suite aux évolutions sus-citées, Digia continue de soutenir le site communautaire http://qt-project.org/ sur lequel on peut trouver différentes règles concernant l'ajout de code à Qt. Le code source est pleinement disponible et géré avec Git (git://gitorious.org/qt/qt.git). Un système élaboré de relecture de code a été mis en place utilisant Gerrit.
Le développement est donc ouvert à toutes les bonnes volontés, avec un accès au code facilité (outils classiques) et une politique d'inclusion publique.
Modularisation
Qt devenant de plus en plus gros en nombre de fonctionnalités, le code source a été réparti dans plusieurs dépôts git de manière à faciliter le développement. Ainsi, le code de QtQuick ou celui de QtWebkit ne font plus partie du dépôt git contenant les bibliothèques de base.
Compatibilité source
Un des objectifs de Qt 5 est de conserver au maximum la compatibilité source avec Qt 4.x. Le portage d'application devrait donc être simple et consister en une simple recompilation.
QPA par défaut
QPA (Qt Platform Abstraction) avait vu le jour avec Qt 4.8 (voir la dépêche sur le sujet). C'est une couche d'abstraction qui facilite le port de Qt sur différentes plateformes via des plugins en lieu et place de #ifdef
dans le code. QPA est maintenant utilisé par défaut sur toutes les plateformes y compris Windows, Mac OS X et Linux.
Sous Linux, c'est XCB qui est maintenant utilisé par défaut pour communiquer avec le serveur X11. Il existe aussi un plugin pour Wayland qui est le système d'affichage recommandé pour l'embarqué.
QPA est aussi la fondation des ports vers iOS et Android. Ces derniers seront officiellement supportés par Digia à partir de Qt 5.1.
Ajouts
- gestion du DNS (SRV, TXT et MX) au lieu de la seule résolution de nom de Qt4
- lecteur et générateur JSON
- gestion des types MIME (sur extension et sur contenu, même en mémoire)
- prise en charge des souris de joueur (nombre de boutons gérés en fonction de l'interface graphique, mais jusqu'à 27 boutons sous X)
- utilisation des nouveautés de C++11 quand le compilateur le permet.
QML et QtQuick 2.0
Une des principales évolutions de Qt est QtQuick. Pour rappel, QML, qui avait été introduit dans Qt 4.7, est un nouveau langage de description d'interface pour Qt, utilisant Javascript. QtQuick est le nom pour l'ensemble des technologies autour de QML.
QtQuick 2.0 est un changement majeur. Il n'est pas compatible avec QtQuick 1.x, c'est pourquoi un module de compatibilité existe pour que les applications écrites avec Qt 4.x utilisant QML continuent de fonctionner.
Le principal changement de QtQuick 2.0 est la réécriture du moteur d'affichage utilisant un Graphe de scène basé sur OpenGL. Le rendu est maintenant effectué dans un thread séparé, permettant de rendre de manière fluide des animations complexes.
Le moteur de JavaScript de QML a aussi été changé. V8 (le moteur JavaScript écrit par Google) est utilisé en lieu et place de QtScript (qui utilise JavaScriptCore). La raison du changement est une meilleur stabilité de l'API de V8 au cours du temps.
Le développement de QML est annoncé comme largement prioritaire sur les classiques QWidget (incompatibles avec le graphe de scène de QML). Le système à base de QWidget est considéré comme "déjà poussé jusqu'au bout" et ne recevra plus que des corrections de bugs (source: ML qt5-feedback ).
Vérification des signaux/slots à la compilation
Une nouvelle syntaxe fait son apparition pour l'utilisation des signaux et des slots. En Qt4, la syntaxe est la suivante :
connect(sender, SIGNAL(valueChanged(QString,QString)),
receiver, SLOT(updateValue(QString)) );
Le problème est qu'il n'y a aucune vérification sur l'existence des fonctions données à la compilation : ce sera uniquement à l'exécution que cela posera problème. De plus, ce n'est pas compatible avec l'utilisation de typedef
et de namespace
, donc si vous faites une faute de frappe, c'est foutu. Avec Qt5, une nouvelle syntaxe apparaît ; elle ne remplace pas l'ancienne mais s'ajoute à celle-ci, donc pas besoin de changer le code actuel. On peut donc écrire :
connect(sender, &Sender::valueChanged,
receiver, &Receiver::updateValue );
Cette syntaxe permet donc au compilateur de lever une erreur si la fonction n'existe pas mais fonctionne aussi avec typedef
et namespace
. De plus, il est possible d'avoir une conversion de type automatique. Par exemple, un signal envoie un QString
et le slot récupère un QVariant
. Il est aussi possible d'utiliser n'importe quelle fonction comme slot, évitant ainsi le besoin de le déclarer explicitement comme auparavant. Il est même possible d'utiliser une fonction lambda comme slot, facilitant ainsi l'usage de la programmation asynchrone.
connect(sender, &Sender::valueChanged, [=](const QString &newValue) {
receiver->updateValue("senderValue", newValue);
});
D'après des tests réalisés avec un benchmark d'alphaonex86, le système de messages (signaux/slots) a gagné en performance avec Qt5. On gagne en rapidité pour l'établissement de nouvelles connexions, ainsi que pour l'envoi de message.
QML, Webkit et Webkit2
Webkit2 arrive enfin (l'API Webkit2 est sortie en 2010 !), avec un module QML. En fait Qt5 propose Webkit et Webkit2, aux API incompatibles. Outre les nouveautés d'HTML5, « cette version inclut directement dans l'API webkit de base un modèle similaire à Chrome, sépare le contenu de l'UI dans des processus séparés, et peut placer divers contenus dans divers processus » (tiré de ce post explicatif d'Enjolras). Bref, les navigateurs en Qt vont devenir de sérieux concurrents de Safari et Chrome.
Et pour la suite
Le développement de Qt devrait suivre un processus basé sur une version à peu près tous les 6 mois. Les fonctionnalités sont développées dans des branches, et ce qui est considéré comme stable au moment du gel sera inclus dans la prochaine version mineure. Si tout va bien, 5.1 pourrait déjà sortir en avril.
Sont au programme, une plus grande stabilité et l'ajout de modules comme Qt3D et QtSensors qui n'étaient pas prêts pour Qt 5.0.
Qt3D ajoutera la gestion d'objets 3D, des textures, des caméras, la possibilité de scripter du code 3D en QML et le chargement de fichiers .obj et .3ds.
Comme vu plus haut, iOS et Android arriveront comme nouvelle plateforme.
Les Components pour desktop sont également en cours de développement. Ce sont des éléments QML incluant tout ce qu'il faut pour faire des applications de bureau en QML.
Aller plus loin
- Annonce sur le Qt blog chez Digia (272 clics)
- Fonctionnalités Qt 5 (472 clics)
- Compiler Qt 5 depuis Git (240 clics)
- Quoi de neuf dans Qt5 (avec des liens)? (270 clics)
- Problèmes connus (122 clics)
# Projets Qt, y en a aussi pour la médecine
Posté par ericmaeker (site web personnel) . Évalué à 10.
Avec FreeMedForms :D
Et d'autres (comme Sofa par exemple)…
http://www.freemedforms.com
[^] # Re: Projets Qt, y en a aussi pour la médecine
Posté par ericmaeker (site web personnel) . Évalué à 10.
Bon voilà, une journée de taf et toute la suite FreeMedForms est portée à Qt5 (mais reste 100% compatible 4.8x). Merci QtCreator (dont FreeMedForms emprunte qq lignes). Finalement, ça n'a pas été si compliqué que ça. Je me rappelle avoir travaillé sur un projet Qt3 alors que Qt4 était déjà à la 4.4, le portage était carrément impossible (sauf à y passer des semaines entières). On dirait que les équipes de Qt ont tiré les leçons de ce douloureux passage.
http://www.freemedforms.com
[^] # Re: Projets Qt, y en a aussi pour la médecine
Posté par EdB . Évalué à 9.
Il me semble que le passage Qt3 Qt4 était nécessaire pour poser de nouvelles fondations et permettre une meilleur évolution.
Du coup, c'est peut être ce qui à permis un Qt4 Qt5 plus facile.
# Opera n'utilise plus Qt
Posté par deronnax . Évalué à 0.
Depuis la 10.5, depuis un petit bout de temps donc. Il utilise directement X11.
http://www.omgubuntu.co.uk/2009/12/opera-10-5-for-linux-ditches-qt-is-faster-than-chrome
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.