En direct des Qt DevDays 2012

[LittleWhite]

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.

[LittleWhite]

Nous avons pris l'après-midi à voir toutes les techniques pour recréer les différents types de lumières comme elles l'étaient dans le pipeline fixe, mais, cette fois, tout en OpenGL 3.3 sans pipeline fixe. Chacun des effets suivants a été revu :

• lumière ambiante ;
• lumière diffuse ;
• lumière spéculaire ;
• point lumineux, spot et lumière directionnelle ;
• toon shading ;
• brouillard.

Ensuite, nous avons revu les techniques liées aux textures :

• multi texturing ;
• bump mapping ;
• diffuse mapping ;
• ambient occlusion.

[LittleWhite]

Il est vrai qu'hier je n'ai pas donné beaucoup d'informations techniques. Maintenant que j'ai un peu plus de temps, je peux vous expliquer les nouveautés dans la création d'applications OpenGL de Qt 5.

Initialisation d'OpenGL dans Qt 5

Tout d'abord, si vous voulez faire une fenêtre utilisant OpenGL, vous n'avez plus besoin d'hériter votre classe de QGLWidget mais simplement de la nouvelle classe QWindow (qui remplace QWidget). Lors de sa construction, vous devriez appeler la fonction setSurfaceType() avec comme paramètre OpenGLSurface afin d'avoir une fenêtre OpenGL. Voici l'exemple d'une classe Window qui hérite de QWindow afin de mettre en place une fenêtre OpenGL :

Code :

1
2
3
4
5
6
7
Window::Window( QScreen* screen )
    	: QWindow( screen )
{
    // Indique à Qt que nous allons utiliser OpenGL avec cette fenêtre
    setSurfaceType(OpenGLSurface);
 
    ...

(Note : QWindow hérite de QSurface)

Toutefois, nous n'avons pas encore configuré OpenGL. Pour cela, nous utilisons deux classes :

• QSurfaceFormat
• QOpenGLContext

Sean Harmer compare QSurfaceFormat à un papier et QOpenGLContext à un crayon.

Plus précisément, QSurfaceFormat permet de définir la version d'OpenGL (setMajorVersion() et setMinorVersion()), le profile (core ou deprecated) à utiliser (setProtile()), mais aussi le niveau de multisampling (anti-aliasing), la taille du buffer de profondeur, ...

Code :

1
2
3
4
5
6
7
// Spécifie le format que nous voulons
QSurfaceFormat format;
format.setDepthBufferSize( 24 );
format.setMajorVersion( 3 );
format.setMinorVersion( 3 );
format.setSamples( 4 );
format.setProfile( QSurfaceFormat::CoreProfile );

Une fois le format configuré, il faut l'indiquer au QOpenGLContext :

Code :

1
2
3
4
// Créer un contexte OpenGL
m_context = new QOpenGLContext;
m_context->setFormat( format );
m_context->create();

Le contexte doit par la suite être passé à une scène (classe héritant de QAbstractScene).

Chaque fois que vous devez agir sur ce contexte OpenGL (initialisation d'OpenGL, mis à jour des buffers, affichage, ...) il faut rendre le context actif :

Code :

m_context->makeCurrent(this);

(makeCurrent() accepte un paramètre de type pointeur sur QSurface).

(Note : un contexte ne peut être actif que dans un thread à la fois)

Pour l'affichage, nous pouvons imaginer le code suivant :

Code :

1
2
3
4
5
6
7
8
9
10
11
void Window::paintGL()
{
    // Rend le contexte actif
    m_context->makeCurrent( this );
 
    // Effectue le rendu (dans le back buffer)
    m_scene->render();
 
    // Échange les front/back buffers
    m_context->swapBuffers( this );
}

Par défaut, Qt utilise du double buffering.


Gestion des extensions

La gestion a changé dans cette nouvelle version de Qt. Tout d'abord, la classe QOpenGLContext vous permet de récupérer une liste d'extensions sous la forme d'un QSet<QByteArray> avec la méthode extensions(). De plus, cette même classe intègre une seconde fonction : hasExtension() qui retourne un boolean indiquant si l'extension est supportée par la machine ou non.
Bien sur, la fonction getProcAddress() permettant de récupérer les pointeurs de fonctions sur les fonctions des extensions OpenGL est toujours présente. Mais son usage a été limité car elle était source de problèmes. Pour remplacer cet ancien mécanisme, la classe QOpenGLContext expose une fonction functions() qui retourne un QOpenGLFunctions*. Cette dernière contient des méthodes pour appeler les fonctions OpenGL.
Par contre, OpenGLFunctions ne fournit pas toutes les fonctions disponibles dans OpenGL (surtout si une nouvelle spécification OpenGL est créée), ni les fonctions pour toutes les extensions.
De plus, Qt 5 propose des factory de fonctions appelées QOpenGLVersionFunctionsFactory (implémenté sous la forme d'un singleton). Cette classe aurait dû être intégrée directement dans QOpenGLContext, mais elle n'était pas prête pour Qt 5.0. Elle le sera dans Qt 5.1.

L'avantage est que la classe ajoute des vérifications au moment de la compilation.


Le code d'exemple utilisé pendant la formation est disponible : http://qt.developpez.com/evenement/2.../dd-opengl.zip

[LittleWhite]

Deuxième journée aux Qt Dev Days 2012. La matinée était réservée aux keynotes à propos de Qt 5, l'occasion d'en apprendre plus sur le présent et le futur de Qt 5.

En bref, les objectifs autour du projet Qt sont :

• être numéro 1 dans la gestion de plateformes (Jolla, Blackberry 10, Android, iOS, les plateformes embarquées et bien sûr, les plateformes de bureau) ;
• être numéro 1 dans l'expérience développeur (avec l'intégration de nouveaux outils, une meilleure documentation…) ;
• être numéro 1 dans l'expérience utilisateur (prototypage rapide, performance, fluidité, fonctionnalités…) ;
• garder le modèle de double licences (Open Source/commerciale) ;
• renforcer l'écosystème autour de Qt ;
• continuer avec l'architecture ouverte du Qt Project.

Ensuite, Lars Knoll, mainteneur en chef, est venu nous présenter plus en détails Qt 5, dont la seconde bêta est maintenant disponible.
Tout d'abord, Qt 5 sera normalement disponible en décembre. Une fonctionnalité supplémentaire sera ajoutée tous les six mois. Ainsi, Qt 5.1 verra le jour durant le printemps 2013 et Qt 5.2 durant la fin de l'année 2013.
Actuellement, le support de BlackBerry 10 devrait arriver durant le printemps 2013 et le support de iOS et Android dans Qt 5.2.

Lars a aussi annoncé que le projet Qt était une réussite avec 25 000 commits acceptés venant de 450 commiteurs rien qu'en une année.

Ensuite, la keynote est revenue sur Qt 5.

Comme cela avait déjà été annoncé l'année dernière, le code Qt 4 est compatible avec Qt 5 et cela a été confirmé. Qt Creator 2.6 est capable de compiler un projet avec Qt 4 et avec Qt 5.

Qt 5 aura une architecture modulaire permettant d'utiliser et d'embarquer uniquement ce qui est nécessaire. Certains modules de Qt 4 ont été dépréciés (mais restent présents dans Qt 5) :

• Qt OpenGL ;
• Qt XML ;
• Qt SVG ;
• Qt Script et les outils de scripting.

Finalement, Lars Knoll a revu les différentes améliorations de Qt 5 :

• nouvelle abstraction pour le code spécifique aux plateformes (permet de porter Qt plus facilement) ;
• nouvelle architecture graphique, utilisation optimale du GPU ;
• utilisation du C++11, lorsque le compilateur le permet ;
• signaux/slots revus ;
• utilisation de l'Unicode par défaut (les chaines de caractères sont encodées en UTF-8 par défaut) ;

Dans le futur, il est prévu que les composants Qt Quick soient disponibles pour desktops et plateformes tactiles avant l'été prochain. Le système de compilation qmake commence à être revu et son successeur, qbs, sera peut-être disponible avant l'été.
Progressivement, les outils seront améliorés, avec le support complet de plus d'add-ons.

[LittleWhite]

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 :

-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 :

Qt 5 based 3D Wayland compositor - YouTube

Qt 5 based 3D Wayland compositor - YouTube

(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).

[idiallo]

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/.

[idiallo]

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.

[LittleWhite]

Déployer des applications Qt pour BlackBerry 10

Cette session présentée par RIM a débuté par un historique de l'histoire 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.

On arrive maintenant à la concrétisation de cette histoire, avec Qt 4.8.x porté sur BlackBerry 10.

Actuellement, vous pouvez faire une application pour mobiles de quatre manières différentes (comme montré dans la pièce jointe). L'une d'entre elle (celle qui nous intéressera le plus) 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.

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 utilisateur à travers Qt Creator.

Les applications BlackBerry possèdent quelques particularités, comme celle de nécessiter un fichier XML pour décrire l'application (voir photo en pièce jointe).

Actuellement, il est possible de télécharger le NDK en bêta sur le site de RIM et de tester dès à présent le développement pour BlackBerry 10.

[LittleWhite]

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.

[LittleWhite]

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) :

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

[LittleWhite]

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.

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 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.)

[LittleWhite]

À 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/.

[LittleWhite]

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 :

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.

[froggy25]

Merci pour ces compte-rendus, bon boulot

*a de la lecture*

[idiallo]

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.