Compte rendu Qt Developer Days 2012

Les Qt DevDays sont un événement annuel permettant aux développeurs du framework Qt de présenter les nouveautés aux professionnels. C'est aussi l'occasion pour les personnes assistant à l'événement de rencontrer d'autres développeurs Qt, d'assister à des conférences, de discuter avec les développeurs de Qt et experts de la technologie et de découvrir des projets innovants utilisant Qt.

Ainsi, sur trois jours, une cinquantaine de sessions et séminaires ont eu lieu. Pour rappel, le premier jour est une journée de formation afin d'apprendre à utiliser un nouveau module de Qt ou de se remettre à niveau pour participer aux conférences des deux jours qui suivent.

Ces deux autres journées permettent d'en apprendre plus sur ce qu'allaient être Qt 5, Qt Quick 2, l'évolution envisagée de Qt et son support sur les différentes plateformes du marché, que ce soit les téléphones, les PC ou encore les systèmes embarqués.

Qt 5 approche à grands pas. À l'occasion des Qt Developer Days, la seconde bêta de Qt 5 a été publiée. L'événement a été l'occasion d'en apprendre plus sur les nouveautés de Qt 5 et les changements apportés par cette mouture. Ce n'est pas tout : une description des fonctionnalités principales a été donnée pour les versions Qt 5.1 et Qt 5.2, qui sont prévues pour le courant de l'année 2013.

Le second aspect important de cette année est le transfert de Qt à Digia. Comme vous avez pu le remarquer sur l'affiche, le nom de Nokia n'apparait pas. En effet, après un moment d'incertitude sur la préparation de l'événement, KDAB et ICS ont repris le flambeau de l'organisation, Digia s'étant joint à eux plus tardivement. Les keynotes du mardi matin nous ont appris que Qt n'a rien subi à cause du transfert de propriétaire, et cela, grâce à l'open governance.

Finalement, après une année d'open governance, les premiers résultats sont prometteurs et montrent que cette nouvelle gestion fonctionne et apporte des bénéfices au projet Qt.

Tommi Laitinen de Digia a énoncé les objectifs que l'entreprise veut faire atteindre à Qt :

- être le numéro un dans la gestion de plateformes (BlackBerry 10 qui repose en partie sur Qt, mais pas seulement, comme cela est présenté plus loin) ;

- être le numéro un dans l'expérience développeur (meilleurs outils, meilleure documentation, etc.) ;

- être le numéro un dans l'expérience utilisateur (interface fluide, fonctionnalités, performances, etc.) ;

- garder le modèle à double licence (Open Source et commerciale) ;

- renforcer l'écosystème autour de Qt (par exemple, par le développement de partenariats) ;

- garder l'architecture ouverte du Qt Project.

Ensuite, Lars Knoll, mainteneur en chef, est arrivé en scène pour décrire d'un point de vue technique l'évolution arrivant avec Qt 5 et la suite, car Qt ne s'arrête pas à la version 5.

En introduction à sa keynote, Lars a annoncé la disponibilité de la bêta 2 de Qt (Qt 5 est maintenant disponible).

II-B-1. Futur de Qt▲

II-B-2. Nouveautés de Qt 5▲

Finalement, Thiago Maciera a parlé de l'Open Governence. Pendant sa présentation, nous avons pu voir un graphique retraçant les différents commits de l'année sur le Qt Project, par entreprise. Parmi les points forts, on remarque une période où le nombre de commits a fortement diminué, à l'annonce de l'abandon du support de Nokia. Sinon, le développement de Qt est stable et la récente diminution marque le blocage des fonctionnalités en vue de la sortie de Qt 5.

Clairement, la conclusion du graphique et de la keynote est que l'Open Governance a permis à Qt de survivre à l'abandon par Nokia. Durant cette année le Qt Project a reçu 25 000 commits (acceptés) de 450 commiters.

Par la suite, Thiago nous a rappelé la facilité avec laquelle il est possible de s'intégrer dans le Qt Project. Grâce à son architecture pyramidale, l'intégration dans le projet suit le niveau d'expertise des participants. En effet, si vous êtes complètement étranger au projet, le plus simple sera de suivre les mailing lists. Ensuite, vous saurez comment faire votre premier commit, puis de nouveaux et, si vous êtes assidu, vous pourrez même être promu « approver » (personne approuvant les commits des autres développeurs). Si vous n'en restez pas là et que votre travail continue sur Qt, il vous sera peut-être proposé la place de mainteneur pour votre module dans lequel vous êtes devenu expert. C'est cette architecture qui permet à tout le monde de s'insérer dans le projet et d'y participer.

Vous pouvez télécharger le support de cette keynote.

Après que les conférences ont été finies, quelques keynotes moins importantes ont eu lieu. Alec Sauncers, Vice President de QNX Software Systems Ltd, nous a parlé de BlackBerry 10 avec ou sans rapport avec Qt.

En effet, la présentation a commencé par quelques faits :

- les revenus des applications BlackBerry sont supérieurs à ceux des autres systèmes ;

- les applications BlackBerry coûtent moins cher à développer.

Ensuite, nous avons pu voir BlackBerry 10 en démonstration. Le système s'inspire de ses concurrents tout en apportant des améliorations qui plaisent à l'œil mais qui ne sont pas de première nécessité. En effet, on peut voir pendant la transition, en transparence, les éléments qui vont arriver sur l'écran.

Le clavier pour écrire du texte autocomplète le texte (en devinant les mots - qui s'affichent en transparence sur les lettres du clavier). De plus, il est capable de deviner la langue utilisée par l'utilisateur (énorme avantage si on écrit un texte en plusieurs langues).

RIM fait tout pour avoir énormément d'applications pour son système. Par exemple, il y a quatre façons de développer une application pour BlackBerry 10 :

- C++ (Qt ou Cascades) ;

- HTML 5 ;

- Adobe Air ;

- Android.

Pour les applications Android, il y a tout de même quelques limites. Les applications Jelly Bean ne sont pas encore acceptées. De plus, il ne faut pas que l'application utilise les API payantes de Google (car le support d'Android repose sur la version Open Source).

De plus, RIM organise plusieurs événements pour les développeurs. Des événements techniques un peu partout dans le monde offrant une occasion de rencontrer les professionnels pour avoir du support sur son application.

RIM offrait 100 € pour porter une application durant les Qt Dev Days.

De plus, RIM organise un parrainage au cours duquel la société assurera que vous gagnez 10 000 dollars si vous développez une application faisant 1000 dollars de revenus.

On comprend très bien que les applications sont une priorité pour la réussite de l'écosystème.

Nous avons aussi pu voir une application Qt Quick avec Box2D (un moteur physique 2D) fonctionner sur l'appareil. Le portage semble très facile, car Qt est parfaitement géré par le système.

Finalement, quelques petits points cités :

- le meilleur support de HTML 5 (que ce soit pour bureau ou pour mobile) ;

- si vous ne respectez pas la vie privée de l'utilisateur, votre application sera rejetée ;

- pour l'instant, les applications GPLv3 ne sont pas acceptées (mais pourraient l'être dans le futur).

Vous pouvez trouver plus d'informations sur le portage d'applications Qt pour le BlackBerry 10 sur le blog de développement : http://devblog.blackberry.com/.

Cette dernière keynote était plus amusante. Eirik Chambe-Eng (l'ex-président de TrollTech) nous a présenté quelques-uns des easter eggs (ajout de code amusant et souvent inutile) de Qt.

Pour ceux qui ont connu les premières années de Qt, le logo était bleu (pendant les six premières années de la bibliothèque).

Dans le fichier Ism de Qt 0.90 (la première version publique), l'équipe avait inclus une typo :

qt-buts@trolltech.no

à la place de :

qt-bugs@trolltech.no

Le chargement des noms des polices de X11 utilisait un nombre magique, qui semble avoir été réutilisé dans GTK.

Q_METHOD est un symbole qui existe dans les fichiers d'entêtes de Qt, mais n'a jamais été utilisé. Celui-ci existe depuis Qt 0.90 et aurait dû être utilisé pour un système de scripting. Malgré sa non-utilisation, le symbole était encore présent dans la première bêta de Qt 5.

Dans Qt 0.90 à 1.2, la fonction écrivant les fichiers XPM (fichier image sous une forme de texte) choisit, comme première couleur, une couleur appelée "Qt".

Dans Qt 0.90 à 1.2, le programme d'exemples widget affiche le logo de Qt dans la QList à la ligne 42. Ces versions avaient un style OS/2 (depuis, celui-ci a été retiré, le système étant mort).

Dans Qt 2, jusqu'à 3.2, si on appuie sur Ctrl + Alt, puis 't' 'r' 'o' 'l' 'l' , une boite de dialogue nommée "Egg" s'ouvre.

Dans Qt 4.2, dans la boite de dialogue d'informations du designer, si on maintient le clic sur le logo et que l'on glisse le curseur sur les pixels noirs du logo, un bouton apparait. En cliquant sur le bouton un jeu apparait, affichant un labyrinthe dans lequel on peut collecter les cartes de visite des développeurs.

Qt and the Google APIs, ICS

Le support de présentation est disponible.

Les API Google sont des services basés sur SOAP destinés principalement aux applications web, mais pas seulement.

ICS a créé et mis à disposition en licence GPL (LGPL probablement bientôt) des interfaces Qt pour 18 services Google :

- OAuth (authentification, dépendance pour d'autres services) ;

- Tasks (gestion de tâches) ;

- Maps, dont Street View ;

- Latitude (localisation) ;

- Blogger ;

- Calendar (agenda) ;

- Drive (stockage de fichiers dans le cloud) ;

- Freebase (base de connaissances reliée dans un graphe) ;

- Places (infos sur l'environnement de l'utilisateur) ;

- Shopping (informations sur des produits) ;

- Big Query (requêtes) ;

- Predictions (moteur de prédictions, puissant mais nécessite de définir ses modèles) ;

- Earth (seulement sur Windows).

Attention, certains services sont payants au-dessus d'un plafond d'utilisation (Prediction, par exemple).

Ces interfaces sont disponibles pour Qt en C++ (Linux/Windows/Mac OS X) et QML (N9 et Symbian) ; elles pourraient être intégrées comme module add-on de Qt dans le futur.

QML for desktop apps, par Michael Wagner et Helmut Sedding

Le support de présentation est disponible.

La conférence avait pour but de nous montrer qu'une application lourde (un logiciel de visualisation et d'édition de chaînes de montage, en 3D) pouvait être réalisée avec QML. En effet, souvent, les développeurs imaginent que QML n'est utile que pour du prototypage ou des applications mobiles, mais cela n'est pas la réalité. L'interface en QML affichait une vue en 3D dans laquelle il était possible de sélectionner, déplacer et modifier les éléments. Une seconde vue, cette fois-ci en 2D, mais toujours en QML permettait de voir la chaine de travail vue de dessus. De même, il était possible de modifier les éléments de la chaîne en temps réel. Celle-ci a été réalisée en se basant sur l'élément basique « Flickable ». Ainsi, plus aucun doute n'est possible, il est tout à fait réalisable de créer une application complexe et de la présenter avec QML.

Afin de réaliser des listes de données filtrables, il est possible de chainer les ProxyModel afin de filtrer des données précédemment filtrées.

Qt and Cloud Services, par Sami Makkonen, Digia

Le support de la présentation est disponible.

La présentation récapitule les différents modèles "cloud", avec des exemples par catégories :

- Saas, Software as a service, comme les Google Apps, Dropbox ;

- Baas, Backend as a service, comme Firebase, Apigee ;

- Paas, Platform as a service, comme Google App Engine, AWS ;

- Iaas, Infrastructure as a service, comme Rackspace, AWS.

Plusieurs briques de base pour l'utilisation de services cloud sont déjà disponibles dans Qt : gestion du XML, classes, Network, JSON, SOAP...

Toujours côté Qt, un projet de recherche de l'université de Jyväskylä expérimente l'intégration avec les services Amazon (AWS) et MS Azure pour le stockage de fichiers. Il a été proposé comme projet pour le « playground » Qt.

La session se termine par une présentation d'un projet Baas de Digia : engin.io, qui fournit des services aux applications et aux développeurs : stockage des données, gestion des environnements de développement/test/production.

La démo de codage est assez impressionnante, l'utilisation de base est vraiment très simple. Il utilise en interne (entre autres) MongoDB (pour le stockage) et Amazon S3 (pour le load balancing).

En plus de l'API Qt (QML) réglementaire, des API existent pour de nombreux autres langages. Il sort bientôt en bêta, on peut s'inscrire sur le site pour manifester son intérêt.

Developing with Qt for the BlackBerry 10, par Vladimir Minenko, RIM

Le support de la présentation est disponible.

Cette session présentée par RIM a débuté par un historique de la collaboration entre Qt et RIM. Tout commença donc en novembre 2011 avec une présentation assez particulière annonçant que Qt serait porté sur les appareils RIM. Une année plus tard, l'histoire se concrétise et Qt 4.8.x porté sur BlackBerry 10.

Actuellement, vous pouvez créer une application pour mobiles BlackBerry 10 de quatre manières différentes. L'une d'entre elles utilise le C++ avec Qt ou Cascades. Cascades est une bibliothèque d'interface utilisateur créée par RIM. Sa particularité est de supporter le C++ mais aussi le QML pour la conception de l'interface.

Cascades est basé sur Qt et sera facile à utiliser par les développeurs Qt. La seule particularité est que Cascades utilise son propre graphe de scène (ayant une architecture client/serveur) et ne permet donc pas d'utiliser l'API de Qt pour le rendu (donc Qt GUI) dans une application Cascades.

Autre petite mauvaise nouvelle : Qt WebKit n'est pour l'instant pas supporté. En effet, RIM a eu quelques difficultés dans le portage et ne pourra pas l'intégrer pour la publication de BlackBerry 10. Toutefois, les développeurs travaillent dessus et son support devrait être réalisé courant 2013.

Parmi les bonnes nouvelles, nous avons pu remarquer que la création d'une application Qt pour BlackBerry est simple. En effet, RIM propose un plug-in pour Qt Creator 2.6.x afin d'avoir un template de projet et de déployer directement son application sur le BlackBerry. Grâce à son NDK, RIM propose aussi un simulateur à travers Qt Creator.

Les applications BlackBerry possèdent quelques particularités, comme celle de nécessiter un fichier XML pour décrire l'application.

Bien entendu, celui-ci sera généré par Qt Creator à travers le plugin de RIM.

RIM tient à la vie privée des utilisateurs. Pour cela, chaque application sera vérifiée sur le store et en plus, chacune d'elles s'exécute dans un espace particulier (sandbox).

In Depth - QMetaType and QmetaObject, par Stephen Kelly, KDAB

Le support de la présentation est disponible.

Le but de cette présentation était de présenter ce qui se cache derrière système de typage de Qt, qui je le rappelle, permet d'enregistrer de nouveaux types dans le cœur de Qt. Stephen Kelly a débuté par nous présenter les améliorations qu'apporte le C++11 pour l'introspection et la reconnaissance des types. Le N3437 propose d'identifier les types avec des chaînes de caractères.

Ensuite, Stephen a détaillé le fonctionnement de QVariant. Celui-ci utilise un entier pour identifier le type contenu. C'est ensuite QMetaType qui permet d'ajouter un nouveau type dans le moteur de Qt et qui fera la correspondance entre les entiers et les types sous forme de chaine de caractères.

Du côté des fonctionnalités disponibles au moment de la compilation (donc sans coût pour l'exécution du programme), il y a le moc et les QObject. Vous interagissez avec le moc à chaque fois que vous utilisez les macros comme Q_OBJECT, Q_PROPERTY…

Avec Qt 5, ce système sera amélioré. La déclaration des métatypes sera automatique et il n'y aura donc plus besoin de Q_DECLARE_METATYPE. Cela est vrai pour toutes les classes héritant de QObject, les conteneurs Qt et les pointeurs intelligents Qt. De plus, il n'y aura plus besoin de qRegisterMetaType dans la plupart des cas. Le code pour enregistrer les types est généré par le moc.

Creating Window Compositors with the Qt Wayland module, par Andy Nichols, Digia

Le support de la présentation est disponible.

Tout d'abord, il faut savoir que Wayland est un protocole pour les compositeurs (ce qui contient les fenêtres) afin de parler à leurs clients au travers d'une bibliothèque C. Les compositeurs peuvent être des serveurs d'affichage fonctionnant avec Linux, des applications X ou encore un client Wayland lui-même. Les clients peuvent être des applications traditionnelles, des serveurs X (rootless ou fullscreen) ou d'autres serveurs d'affichage.

L'avantage de Wayland est qu'il utilise une mémoire partagée entre les clients afin d'écrire des informations à afficher. Cette mémoire peut être implémentée grâce à un simple système de mémoire partagée ou à travers des buffers GPU (plus rapide encore, car cette méthode évite les coûts d'envoi des données au GPU).

Wayland a l'avantage d'être extensible, rapide, léger et personnalisable. À terme, il pourrait remplacer X11.

Revenons maintenant à Qt. Jusqu'à Qt 4, le système gérant l'affichage des widgets pour les plateformes embarquées était appelé QWS, pour Qt Windowing System. Le problème de ce dernier est qu'il était compliqué d'implémenter de nouvelles plateformes ou même de supporter OpenGL pour gérer l'affichage des fenêtres. C'est pourquoi QWS a été supprimé dans Qt 5. Maintenant, si vous voulez implémenter un nouveau gestionnaire d'affichage, il faudra passer par QPA (Qt Platform Architecture). Qt Wayland propose une implémentation des spécifications Wayland et fournit une méthode pour implémenter un compositeur Wayland mais aussi des applications clientes s'intégrant aux compositeurs Wayland.

Avec Qt 5.0, pour lancer une application utilisant cette nouvelle plateforme, il suffit d'ajouter :

-platform wayland

Avec cette implémentation, Qt propose une série de nouvelles classes permettant de créer facilement vos propres compositeurs (vos propres interfaces accueillant l'affichage d'autres applications).

WaylandCompositor est la classe principale du compositeur dont il faut hériter afin de créer son compositeur. Dans celle-ci, il est nécessaire de réimplémenter la fonction surfaceCreated() et d'appeler frameFinished() une fois que le rendu des surfaces est terminé.

WaylandSurface représente les surfaces qui seront affichées par les clients. Lors de la réception d'une nouvelle surface avec WaylandCompositor::surfaceCreated(), il est nécessaire de connecter les signaux afin d'être informé des régions qui doivent être dessinées. Il est par contre nécessaire de vérifier les données reçues à travers les signaux car elles peuvent être soit des textures OpenGL, soit des segments de mémoire partagée.

Finalement, WaylandInputDevice, permet de transmettre les événements utilisateur aux clients (d'envoyer les clics qui sont effectués à partir du compositeur aux applications intégrées dans celui-ci). Ce dernier gère aussi le focus.

Tout cela permet de faire un compositeur accueillant d'autres applications, comme dans la vidéo suivante :

CMake with Qt, par Stephen Kelly, KDAB

Le support de la présentation est disponible.

Pour rappel, CMake est un outil permettant de créer les fichiers du projet afin de compiler ce dernier, comme les Makefile, les fichiers de projet pour Visual Studio ou Xcode. Pour ce faire, CMake recherche les dépendances afin d'ajouter les options de compilation nécessaires, les chemins vers les fichiers d'en-tête et les bibliothèques à inclure.

En réalité, CMake a été développé avec trois autres outils :

• CPack, pour créer des paquets de l'application ;
• CTest, pour effectuer des tests unitaires (peut fonctionner avec le système de tests de Qt) ;
• CDash, un serveur pour afficher les résultats des tests.

Même s'il existe qmake, il est possible de compiler ses projets Qt avec CMake. Voici un exemple fichier de configuration de projet Qt pour CMake :

find_package(Qt4 REQUIRED QtCore QtGui)

include_directories(${QT_INCLUDES})
add_definitions(${QT_DEFINITIONS})

add_executable(myexe WIN32 main.cpp)
target_link_libraries(myexe
    ${QT_QTCORE_LIBRARIES}
    ${QT_QTGUI_LIBRARIES}
)

Il est évident de trouver que les fichiers .pro sont plus simples que les fichiers de Cmake, mais il ne faut pas oublier que ces derniers sont généralistes et peuvent être utilisés pour toute sorte de projets.

Les fichiers de configuration de CMake pour un projet Qt 5 possèdent quelques différences :

find_package(Qt5Widgets)

include_directories(${Qt5Widgets_INCLUDE_DIRS})
add_definitions(${Qt5Widgets_DEFINITIONS})
set(CMAKE_POSITION_INDEPENDENT_CODE ON)

add_executable(myexe WIN32 main.cpp)
target_link_libraries(myexe
    ${Qt5Widgets_LIBRARIES}
)

Cette lourdeur sera bientôt de l'histoire ancienne. En effet, CMake et son fonctionnement changent. La technique utilisée pour trouver les dépendances des projets (bibliothèques et fichiers d'en-tête nécessaires) sera grandement améliorée et, courant 2013, les fichiers pour CMake ressembleront à ceci :

find_package(Qt5Widgets)

add_executable(myexe WIN32 main.cpp)
target_link_libraries(myexe
    Qt5::Widgets
)

La bonne nouvelle, c'est que, comme CMake est indépendant de Qt, ces changements fonctionneront aussi pour Qt 4.

Avec Qt 5, il faudra rajouter la ligne suivante afin de réussir la compilation.

set(CMAKE_POSITION_INDEPENDENT_CODE ON)

Par la même occasion, les problèmes de liaisons des projets utilisant QTestLib seront réglés (autour de janvier avec la sortie de CMake 2.8.11).

De plus, la fonction qt4_wrap_cpp pour appeler moc sur les fichiers cpp ne sera plus nécessaire, car CMake détectera de lui-même si le moc est nécessaire directement en examinant les fichiers sources. Par contre, la fonction qt4_wrap_ui sera toujours nécessaire.

Finalement, avec CMake 2.8.10, il sera facilement possible d'ajouter des options aux cibles de compilation avec la syntaxe suivante :

$<$<CONFIG.Debug>:/usr/bin/valgrind>

La variable CONFIG contiendra valgrind uniquement pour la cible Debug (et ne sera donc pas présente en release).

III-G-1. Addons Qt pour tout le monde : KDE Frameworks 5▲

Effective QML: Best practices for Developing with Qt Quick, par Adenilson Cavalvanti, ICS

Le support de présentation est disponible (partie 1, partie 2).

Durant cette séance, il nous a été possible d'apprendre quelques astuces pour améliorer nos applications. Tout d'abord, il nous a été rappelé que la création d'une application en QML est moins coûteuse en temps de développement et en complexité du code que de faire une interface en C++. Après un rapide récapitulatif du développement en général, différents rappels et astuces ont été présentés.

Dans un code QML, pour les chaines de caractères, il ne faut pas oublier d'utiliser qsTr() pour gérer l'internationalisation. De plus, pour les fichiers de ressources, il ne faut pas passer par les qrc car le code QML doit être indépendant de l'application. Bien entendu, il est toujours préférable d'enlever les éléments inutiles.

D'autres conseils portaient sur la création des widgets. Pour chacun d'eux, il faut définir une taille minimale. De plus, il est prudent de tester si les propriétés sont définies.

Ensuite, Adenilson Cavalvanti a aussi expliqué que l'approche orientée objet était primordiale. Les propriétés doivent permettre l'exposition de la configuration, d'où la nécessité de créer des interfaces publiques.

De plus, les widgets doivent être encapsulés et il ne faut absolument pas accéder aux éléments par leurs propriétés. Les applications complexes bénéficient d'un contrôleur en C++ pour les traitements de données.

Finalement, il ne faut pas abuser des ListView et penser à utiliser les Repeater. Pour le chargement, il est préférable de permettre un chargement par module, afin d'alléger le démarrage de l'application et surtout, sa consommation en mémoire. N'hésitez pas à penser au chargement asynchrone.

Pour l'optimisation de l'application, il est possible d'écrire des kernels OpenCL en QML. Aussi, il est prudent d'éviter les pointeurs.

SoDeclarative - a declarative wrapper for OpenInventor, par Helmut Sedding/Michael T. Wagner

Le support de la présentation est disponible.

IPOPlan a présenté son logiciel IPO.Log basé sur Qt 4.8 et QML. Le logiciel contient entre autres une vue 3D en QML (avec Qt 4.8).

Helmut Sedding et Michael T. Wagner nous ont expliqué qu'ils avaient créé une implémentation de OpenInventor, le célèbre graphe de scène de SGI, dans QML. Ainsi, il est aisé de créer de nouveaux objets et scènes avec le langage déclaratif.

Pour cela, ils ont scanné les fichiers sources d'OpenInventor afin de les convertir en vue de leur intégration en QML. Au final, il suffit d'inclure SoDeclarative au début de son fichier pour avoir accès aux différents éléments 3D d'OpenInventor. Il devient donc possible de voir les modifications du code en temps réel dans un viewer QML.

Leur projet est disponible sous licence LGPL sur BitBucket.

QML Coding, Performance and Debugging: Usage of Tools, par Aurindam Jana, Digia

Le support de la présentation est disponible.

Cette présentation énumérait les outils présents dans Qt Creator afin de créer, déboguer et profiler le code QML.

Dans les outils de création d'interfaces en QML, nous pouvons soit utiliser l'éditeur de code, proposant une coloration syntaxique, une barre d'outils spécifique à Qt Quick, des options de refactorisation ou utiliser le designer permettant à un non-programmeur de créer ces interfaces en glissant/déposant les éléments.

L'une des fonctionnalités de refactorisation présentée est la possibilité de sélectionner un bloc de code QML et de demander à Qt Creator de l'exporter dans un nouveau fichier afin d'en faire un composant réutilisable.

Qt Creator propose différents outils pour déboguer son code en temps réel. Il est possible de définir un point d'arrêt dans le code QML ou C++ et d'observer les valeurs des variables. Il est aussi possible de parcourir l'arbre des éléments Qt Quick et de modifier les propriétés de ce dernier. Ensuite, un ensemble de fonctions pour afficher des informations dans la console est disponible.

Finalement, l'outil de profiling QML a été présenté. Ce dernier permet d'avoir un diagramme du temps passé dans chaque partie du code (affichage, binding, chargement), de voir les boucles de binding (sorte de boucle infinie spécifique au QML), d'avoir un tableau du temps passé dans chacune des fonctions et de savoir quelles sont les fonctions appelantes et les fonctions appelées.

Chaque fois que le profileur indique une fonction, l'éditeur centre sa vue sur le code pour nous montrer le code lié à la fonction.

Pour activer le débogage des applications QML, il faut compiler l'application avec la variable configurée comme suit (dans le fichier .pro) :

CONFIG+=declarative_debug

ou pour Qt 5

CONFIG+=qml_debug

(puisque le module declarative s'appelera "qml" dans Qt 5).

De plus, avec Qt 5 il sera possible d'arrêter le débogueur sur les exceptions JavaScript. Finalement, Qt 5 apportera un profiler QML sous la forme d'une application externe (non liée à Qt Creator). Ce dernier sauvegardera les informations du profiling dans un fichier XML, chargeable dans Qt Creator.

Pour finir, si vous souhaitez déboguer une application QML compilée à l'aide de CMake, les variables à définir sont :

Pour Qt 4 : QT_DECLARATIVE_DEBUG

Pour Qt 5 : QT_QML_DEBUG