En direct des Qt DevDays 2012
Bonjour à tous,
Actuellement, je suis à Berlin, au Cafe Moskau pour assister aux Qt DevDays 2012.
Comme chaque année, la première journée est réservée aux formations. J'assiste à la formation appelée "Modern OpenGL with Qt5" réalisée par Sean Harmer de KDAB.
Nous avons passé les deux heures de la matinée à voir la création et l'initialisation d'une fenêtre OpenGL dans Qt 5 (il y a quelques changements mineurs par rapport à Qt 4) et l'affichage d'un joli triangle en OpenGL moderne.
Pour cette après-midi, nous allons voir comment envoyer des données aux shaders et différents effets graphiques (phong shading, toon shading, texturing...).
Je vais faire de mon mieux pour vous donner des informations au fur et à mesure.
Compte rendu création de compositeurs avec le module QtWayland
Je sors tout juste de la présentation sur la création des compositeurs avec le module Qt Wayland.
Peut-être avez-vous déjà entendu parler de Wayland récemment, notamment à l'occasion de la sortie en version 1.0 et de ses spécifications.
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 é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 au compositeurs Wayland.
Avec Qt 5.0, pour lancer une application utilisant cette nouvelle plateforme, il suffit d'ajouter :
Citation:
-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 qu'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 utilisateurs 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 :
[ame="http://www.youtube.com/watch?v=_FjuPn7MXMs"]Qt 5 based 3D Wayland compositor - YouTube[/ame]
(Le code est disponible sur gitorious.)
Toutefois, il reste une classe : WaylandSurfaceItem. Celle-ci est une implémentation pour Qt Quick 2.0 de WaylandSurface.
Malheureusement, le module ne sera pas intégré à Qt 5.0 car les spécifications de Wayland ont été publiées deux semaines avant les Qt DevDays, mais cela reste prometteur.
Si vous n'avez pas OpenGL, il reste un moyen de faire fonctionner Qt Wayland. Par contre, vous n'aurez pas Qt Quick 2.0 ni le support des buffers GPU natifs. Il vous faudra utiliser Mesa, implémentant un rendu logiciel (donc plus lent).
Compte-rendu de la présentation "Google APIs avec Qt"
Présentation par Roland Krause (ICS)
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ées 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.
Lien : http://www.ics.com/technologies/qt_google_apis/.
Qt et les services "cloud"
Présentation de Sami Makkonen (Digia)
Un slide bienvenu (ci-joint) 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 beta, on peut s'inscrire sur le site pour manifester son intérêt.
Compte rendu : SoDeclarative
Dernière journée aux Qt Dev Days 2012.
IPOPlan a présenté son logiciel IPO.Log basé sur Qt 4.8 et QML. Le logiciel contient entre autre 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.
Compte rendu : outils QML
Cette présentation a rappelé 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'interface 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 boucle 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) :
Citation:
CONFIG+=declarative_debug
ou pour Qt 5
Citation:
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
4 pièce(s) jointe(s)
Compte rendu : CMake et Qt
La troisième conférence à laquelle j'ai été portait sur CMake et son utilisation avec Qt.
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.
Comme le montre la photo ci-dessus, la configuration d'un projet utilisant Qt est assez compliquée (beaucoup plus qu'avec QMake).
La photo ci-dessous montre la configuration pour un projet Qt 5 :
Tout comme Qt, CMake évolue et il est prévu que le fonctionnement de CMake change. Notamment, la méthode 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 :
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.
Citation:
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 :
Citation:
$<$<CONFIG.Debug>:/usr/bin/valgrind>
La variable CONFIG contiendra valgrind uniquement pour la cible Debug (et donc ne sera pas présent en release).
Finalement, pendant le temps libre laissé par KDAB, Stephen Kelly s'est amusé à implémenter des fichiers de configuration CMake avec le langage QML, comme le montre la photo suivante :
(Bien sur, ceci était principalement pour s'amuser et cela ne sera pas intégré à Qt.)
Compte rendu : Keynote BlackBerry 10
À 15 h, Alec Sauncers, Vice President de QNX Software Systems Ltd, nous a parlé de BlackBerry 10 et de choses pas forcément en 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 est fluide. Les transitions entre les panneaux sont plus fluides et plus belles que sur les autres systèmes. 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 auto complè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 : http://www.developpez.com/redirect/595
On comprend très bien que les applications sont une priorité pour la réussite du systè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/.
Compte rendu : Qt Surprises
Pour finir mes comptes-rendus, je vais vous rapporter une conférence plus amusante. Eirik Chambe-Eng (le 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, écrivant :
Citation:
qt-buts@trolltech.no
à la place de :
Citation:
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.
KDE Frameworks 5 : des add-on pour tous
Présentation par David Faure (KDAB, KDE)
Au fil du temps, le projet KDE a développé kdelibs, un ensemble de composants communs aux applications KDE. Actuellement, kdelibs est une dépendance monolithique, ce qui crée une frontière entre les applications Qt et les applications KDE.
L'objectif pour KDE 5 est de subdiviser kdelibs en modules avec des interdépendances minimales. Trois types de modules ont été créées :
- fonctionnel : modules de type bibliothèque, pas de dépendance à l'exécution ou à des plug-ins ;
- intégration : modules utilisant des fonctions du système ou les implémentant directement et pouvant avoir des dépendances à l'exécution ;
- solution : technologies complètes avec des dépendances à l'exécution.
Ces modules sont également subdivisés en niveaux de dépendance, le niveau 1 ne dépendant que de Qt, le niveau 2 dépendant du niveau 1 et le niveau 3 dépendant des niveaux 1, 2 et 3.
Quelques exemples de modules :
Fonctionnels, niveau 1 : KArchive, Threadweaver, KIdleTime, Dnssd, KConfig ;
Intégration, niveau 1 : Solid ;
Solution, niveaux 2 et 3 : KIO.
Dans KDE Frameworks 5, les modules fonctionnels et intégration seront utilisables comme des ajouts à Qt, ce qui supprimera effectivement la distinction entre applications "purement" Qt et les applications KDE et le problème d'avoir à choisir entre les deux pour le développement d'une application.
L'aboutissement de ce travail est prévu pour courant 2013, avec un code d'abord basé sur Qt 4, pour séparer le travail de modularisation du travail de portage vers Qt 5 qui sera fait dans la foulée.
