Vue d’ensemble

Avant de commencer, une remarque sur Windows. À priori, il est possible de travailler sur Windows. Cependant, les binaires Qt pour Android ne sont disponibles que pour Linux. Comme la compilation de Qt pour Windows est pénible et que je ne l’ai pas faite depuis longtemps, je présente seulement l’utilisation de Linux. Pour ceux qui aimeraient pouvoir utiliser Windows… tant pis pour vous

Je n’avais pas testé Qt sur Android depuis quelques temps, en fait depuis Qt 4.8 et Necessitas. Du coup, j’ai découvert le portage Android dans Qt 5.1 en même temps que je prenais des notes pour cet article. Comme base de travail, je suis parti des pages des pages de documentation de Qt : Qt – Android support.

L’utilisation de Qt sur Android nécessite l’installation de plusieurs outils :

• la version de Qt 5.1 pour Android : ok, on s’y attendait un peu. Contient la bibliothèque complète et Qt Creator ;
• le kit de développement (SDK) pour Android : permet de créer des applications Java pour Android et un simulateur pour tester ses applications ;
• le kit de développement natif (NDK) pour Android : permet de créer des applications C++ pour Android ;
• l’environnement d’exécution de Java (JRE) : nécessaire pour le SDK Android ;
• Apache Ant : pour faire beau. (bon ok, ce n’est pas que pour faire beau, ça sert au déploiement. Mais comme c’est un outil Java, je ne connais pas du tout).

Dans ce tutoriel, je vais montrer l’utilisation de Qt Creator, mais il doit être possible d’utiliser d’autres outils.

Installations

Installation de OpenJDK 7

Pour commencer, il faut installer l’environnement d’exécution de Java. Il est fort possible qu’il soit déjà installé. Dans la documentation, il est indiqué qu’il faut par exemple OpenJDK en version 6 ou plus récente.

Personnellement, j’avais la version 7. Cependant, j’ai eu des problème avec Apache Ant, qui me retournait une erreur. J’ai donc dû installer la version 6 en plus. Comme j’ai pas mal bidouillé, je ne suis pas sûr de la procédure. Si des personnes testent et remarquent des problèmes, n’hésitez pas à me le signaler.

Merci à rotoOm qui m’a indiqué l’origine du problème. Il suffit en fait d’installer le JDK en plus du JRE. Merci à lui pour l’information.

Vous pouvez tester si Java est installé avec la ligne de commande suivante :

Pour l’installation, j’ai donc utilisé les paquets fournis par Ubuntu. Il faut donc juste taper ces lignes de commande :

Pour les autres systèmes Linux, vous pouvez consulter la page de documentation d’OpenJDK : How to download and install prebuilt OpenJDK packages.

Installation d’Apache Ant

Pour l’installation d’Apache Ant, même méthode, j’utilise les paquets Ubuntu :

Pour tester l’installation d’Apache Ant, vous pouvez taper la ligne de commande suivante :

Installation du SDK Android

Pourquoi installer le kit de développement Java ?

Pour commencer, on ne peut se poser une question : pourquoi installer le kit de développement Java et le kit de développement natif et pas simplement ce dernier ? La réponse est simple : parce qu’on ne peut développer que en Java pour Android !

Ok…

Donc cela veut dire qu’il faudra utiliser le binding Java de Qt ? On parlait pas de développement C++ dans ce tutoriel ?

Oui, pas d’inquiétude En fait, il y a un point à savoir sur les applications natives C++ sur Android. C’est une application Java qui appelle un « module » écrit en C++ (on utilise le terme « activité » en Java). Avec Qt, on va donc simplement créer notre code C++/Qt et Qt Creator va s’occuper de créer l’application Java qui appelle notre code.

Ouf !

Installation

L’installation du SDK Android est simple aussi… puisqu’il n’y a pas d’installation à faire. Vous devez simplement télécharger le kit de développement pour Android et décompresser l’archive. Ce SDK contient les outils de développement Android, des plateformes de compilation, l’éditeur Eclipse ADT (Android Developer Tools, configuré spécialement pour Android), un simulateur Android pour tester ses applications.

Pour installer d’autres outils, par exemple d’autres versions de plateforme, vous pouvez utiliser le SDK Manager. Dans Eclipse ADT, allez dans le menu Windows puis Android SDK Manager.

Tester Eclipse

Comme je suis curieux et que j’ai envie de voir un peu comment fonctionne une application Java sur Android, j’ai testé un peu Eclipse et Java. Ceux qui ne sont pas intéressés, vous pouvez passer directement à l’installation du NDK.

Pour cela, j’ai simplement suivi le tutoriel : Building Your First App (il faut reconnaître que la documentation est très claire et simple à suivre, même pour un développeur C++ comme moi).

Allez dans le répertoire d’installation du SDK Android puis dans le répertoire eclipse/. Celui-ci contient un binaire eclipse, que vous lancez. Si c’est la première utilisation d’Eclipse, il va falloir faire quelques réglages de configuration. En premier le Workspace (l’espace de travail d’Eclipse, dans lequel il range les fichiers). Personnellement, j’ai accepté toutes les valeurs par défaut.

Une fois qu’Eclipse est lancé, créez un nouveau projet de type « Android Application Project » dans Fichier puis Créer un projet. Un dialogue permet de donner un nom à votre application (c’est le nom qui apparaîtra sur le téléphone), la version minimale d’Android à prendre en charge et la version Android de destination. J’ai laissé par défaut. Vous pouvez ensuite choisir l’icône de l’application et le type d’activité. Choisissez BlanckActivity, qui va créer une activité « hello world ».

Après quelques minutes (je vais rien dire que la lenteur d’Eclipse…), un projet est créé, qui contient quelques fichiers et répertoires. Les plus importants sont :

• le fichier AndroidManifest.xml : contient les informations sur l’application, en particulier les versions minimale et ciblée de la plateforme ;
• le répertoire res/layout/ : contient les interfaces de l’application, décrites dans des fichiers XML ;
• le répertoire src/ : contient les sources Java du projet. Dans ce projet par défaut, il lance simplement une activité, qui affiche l’interface décrite dans le fichier XML de layouts/ ;
• les répertoires res/drawable-xxx/ : contient les images de l’application.

Comme c’est une application Android, vous ne pouvez pas simplement la lancer comme une application de Bureau classique. Il existe deux méthodes pour la lancer : utiliser un simulateur ou déployer sur un téléphone.

Tester l’application sur simulateur

Pour cela, il faut dans un premier temps créer un simulateur. Le SDK Android est fournit avec un gestionnaire, permettant de créer différentes configurations pour le simulateur, permettant ainsi de tester l’application sur plusieurs types de téléphone.

Allez dans le menu Windows puis Android Virtual Device Manager. Dans le dialogue, créez un nouveau périphérique en cliquant sur « New », puis configurez selon le type de téléphone que vous voulez tester. Par exemple, comme j’ai un téléphone Samsung Galaxy S1, j’ai choisit un écran 4″ en 480*800. Après la création du périphérique, lancez-le.

Lancez ensuite l’application en ouvrant le fichier java (dans src/) puis en cliquant sur le bouton Run. Un dialogue « Run As… » s’ouvre pour choisir comment exécuter l’application. Choisissez Android Application. Normalement, l’application devrait se lancer.

Tester l’application sur téléphone

Bon, un simulateur, c’est bien, mais on aimerait avoir l’application sur un vrai téléphone pour tester. Ce n’est pas très compliqué non plus, mais il va falloir faire une manipulation sur le téléphone. Celle-ci permet d’activer les fonctionnalités de développement du téléphone, en particulier le Debug Mode USB, qui permet de déployer des applications via un cable USB.

Pour Android 4.2, allez dans les paramètres puis dans le menu À propos du téléphone. Cliquez plusieurs fois sur Numéro de build par activer le mode développeur. Vous allez avoir un message confirmant le passage en mode Debug. Revenez ensuite à l’écran précédent et allez dans les options de développeur. Activez le mode Debug USB. Pour les autres versions d’Android, vous pouvez consulter la page suivante : Run on a Real Device.

Pour terminer, il suffit de brancher le téléphone sur l’ordinateur avec un câble USB puis de lancer l’application comme précédemment. L’application devrait se lancer sur le téléphone.

Installation du NDK Android

Rien de compliqué ici non plus, il n’y a pas d’installation à faire, il faut simplement décompresser l’archive.

Installation de Qt Android

Le plus simple, comme indiqué au début de ce tutoriel, est d’utiliser les binaires fournis de Qt 5.1 pour Android. Si vous n’utilisez pas Ubuntu, il vous faudra compiler Qt vous-même. Bon courage

Lancez le binaire Qt pour Android. Le processus d’installation est classique, avec une particularité : le SDK propose par défaut l’installation de Qt Desktop, mais pour Android (versions ARM ou x86), il faut l’activer soi-même. Une fois l’installation finie, allez dans les répertoires Tools, QtCreator, bin puis lancez qtcreator.

La première étape va être de configurer Android. Pour cela, allez dans le menu Outils puis Options. Dans la liste de gauche, allez dans Android, puis configurez les répertoires du SDK et du NDK. Cochez la case pour laisser Qt Creator créer automatiquement les kits de compilation.

Il faut ensuite créer un périphérique pour le simulateur si ce n’est pas encore fait. Pour cela, cliquez sur le bouton Start Android AVD Manager.

Cliquez sur New pour créer un nouveau périphérique. Choisissez le type de Device (pour simuler mon Galaxy S, j’ai donc choisit un 4″ en 480*800). N’oubliez pas d’activer la prise en charge du GPU (Use Host GPU) pour que Qt puisse utiliser OpenGL ES.

Pour créer une application Qt, allez dans le menu Fichier puis Nouveau projet. Choisissez un projet compatible avec Android (par exemple Application Graphique Qt ou Application Qt Quick 2 (élément de base)).

Dans un premier temps, le simulateur se lance.

Puis l’application à la fin du déploiement.

Pour déployer sur un téléphone (préalablement passé en mode Debug USB, voir au début), il suffit simplement de le brancher, Qt Creator lancera alors l’application dessus.

Conclusion

Rien de très compliqué finalement. Le déploiement est relativement simple une fois que les outils sont configurés. Reste plus qu’à tester les performances.

Pour ceux qui sont intéressés par Qt Quick, je rappelle le livre auquel je participe : Créer des applications avec Qt 5 – Les essentiels. J’ai en particulier participé à la rédaction de Qt Quick. C’est encore une pré-version du livre final, mais il y a déjà pas mal de choses sur Qt Quick. Et n’hésitez pas à me dire s’il y a des points que vous souhaiteriez voir abordés dans ce livre.

Si vous êtes intéressé par Qt Quick sur mobile, je fais une présentation le 5 juin à Paris. Contactez-moi par MP pour plus d’informations.

Merci à prgasp77 et winjerome pour leur relecture orthographique.

N’hésitez pas à commenter cet article sur le forum.

Il nous est apparu qu’une faille dangereuse et non détectée par le compilateur résultait de l’utilisation conjointe de la déduction automatique de type retour des lambdas et des std::function<const A&()> qui retournent une référence constante.

Le code suivant compile parfaitement sans aucun warning sous g++4.8 et clang++3.2 avec les flags -pedantic -Wall -Wextra.

Or le résultat obtenu en commentant cette ligne est :

Pour les rapides, oui aref est totalement corrompue, et son utilisation résulte en un crash sauvage et sans pitié du programme lorsqu’on a de la chance. Pour les autres, voici l’explication.

Savez-vous quel est le type de retour implicite de la lambda ci-dessous ?

Si comme moi, à première vue vous répondez A&, vous vous en mordrez les doigts.
La réponse est A.

En effet, comment se déduit automatiquement le type de retour d'une lambda ? Eh bien de la même façon que decltype. C'est à dire tel que la variable a été déclarée. Ici, a étant déclaré comme A, c'est donc A qui est le type du retour de la lambda.

Si l'on capture cette fois une référence vers A :

Ici refTo_a est déclarée comme une A&, c'est donc A& qui sera déduit.

Reprenons notre cas initial. Bon, à priori ce n'est pas une grande perte, on fait une simple copie.

Ainsi, le code suivant est parfaitement sain si on reconnait la légitimité de la copie :

La prise par référence constante allonge bien la durée de vie de la temporaire retournée par la lambda jusqu'à la fin de la vie de la référence, ainsi que la norme le demande.

Oui mais…

Que se passe-t-il lorsque notre lambda est encapsulée dans une std::function<const A&()> ?

Ainsi que cela a été révélé plus haut, mais en ajoutant l'indication du constructeur de copie et un id aux objets la sortie est :

Lors de l'appel à f(), une copie est donc faite, conformément à ce qu'on a vu précédemment avec la déduction automatique du type de la lambda. Mais elle est détruite immédiatement !

Pourtant on récupère bien une const A&, pourquoi ne fait-elle pas prolonger de la copie temporaire comme précédemment ?

Un petit code montrant le mécanisme du avec std::function<const A&()> en détail :

On note à nouveau un silence total du compilateur. Le résultat est :

Là où ça devient tordu c'est que l'extension de durée de vie d'une temporaire par référence constante est limitée à une seule fois.

En effet, une fois récupérée dans une const A&, la copie temporaire n'a plus du tout le statut de temporaire : aussi on ne peut donc plus étendre sa durée de vie de cette façon !

Voici donc le pourquoi du comment. En conclusion il est donc dangereux soit de jouer avec les std::function<const A&()> soit de laisser faire la déduction automatique du type retour des lambdas. En l'absence d'arguments forts pour pencher la balance, la vigilance est donc de mise lorsque l'on joue avec les deux règles responsables du problème ici :

1. Un type de retour automatiquement déduit est équivalent à un decltype(expression_de_return), soit le type de l’expression telle qu’elle a été déclarée, la capture par référence n’y fait rien, ça reste le type de la variable avant sa capture.
2. Si une lambda a vocation à être stockée dans une std::function, alors il faut veiller à ce qu’elle ne renvoie pas une temporaire et que le type de la std::function corresponde au comportement souhaité.

Un grand merci à Flob90 qui a pris le temps de faire beaucoup de tests que vous pouvez consulter ici : lien pastebin. Merci à gbdivers pour sa relecture attentive.

Vous pouvez commenter ce billet de blog sur le forum.

Quelques définitions

Illumination globale

Les techniques d’illuminations globales (GI) visent à améliorer le rendu d’une scène 3D, en prenant en compte aussi bien la lumière directe (les sources de lumières qui éclairent les objets) que la lumière indirecte (réflexion de la lumière sur les objets, qui éclaire d’autres objets). Ces techniques permettent d’obtenir des rendus réalistes, au prix d’un temps de calcul relativement long (parfois trop pour être compatible avec du rendu en temps réel). Un domaine de la recherche actuelle vise à développer de nouveaux algorithmes d’illumination globale compatible avec le temps réel (jeux 3D).

(source : Wikipédia – Illumination globale)

Illumination indirecte

Dans l’illumination directe (à gauche sur l’illustration suivante), la lumière provenant d’une source est directement réfléchie sur une surface, puis renvoyé vers la caméra. C’est le modèle classique de calcul de la lumière en 3D, que l’on retrouve par exemple dans le modèle de Phong. La lumière est alors décomposée en plusieurs composantes : la lumière ambiante (qui représente une illumination globale constante), la lumière diffuse (qui représente une diffusion de la lumière sur la surface) et la lumière spéculaire (qui représente une réflexion sur la surface).

(Source : Real-Time Global Illumination for Point Cloud Scenes)

Dans l’illumination indirecte, on considère que chaque surface qui reçoit de la lumière va à son tour en renvoyer. Il n’y a donc plus qu’une seule source de lumière, mais une infinité, correspondant à chaque surface qui renvoie de la lumière. Pour réaliser le rendu d’une scène, il faut donc procéder de la façon suivante :

1. pour chaque surface S1 visible par la caméra ;
2. pour chaque surface S2 visible depuis la surface S1 ;
3. calculer la lumière reçue par la surface S2 provenant de la source ;
4. calculer la lumière renvoyée par la surface S2 vers la surface S1 ;
5. calculer la lumière reçue par la surface S1 provenant de la surface S2 ;
6. calculer la lumière totale renvoyée par la surface S1 vers la caméra.

Chaque étape doit prendre en compte plusieurs paramètres. Pour (3), il faut par exemple prendre en compte la distance entre la source et la surface S2 et l’atténuation de la lumière en fonction de la distance. Pour (4), il faut prendre en compte les caractéristiques de la surface et sa capacité à réfléchir la lumière. Pour (5), il faut prendre en compte la distance entre les surfaces S1 et S2 et l’angle d’incidence. Pour (6), les capacités de réflexion de la surface S1 et la distance entre la surface S1 et la caméra.

Cette première approche simple peut largement être améliorée (et complexifiée), en prenant en compte par exemple que la lumière peut se réfléchir plusieurs fois sur des surfaces avant d’atteindre la caméra (particulièrement important lorsque les surfaces sont très réfléchissantes, comme du verre ou du métal poli), de la diffusion de la lumière dans le brouillard ou la poussière (lumière volumétrique, éclat lumineux), la présence de plusieurs sources lumineuses (voir des milliers de sources lumineuses dans le cas de particules incandescentes).

Lancé de rayons

Il existe plusieurs techniques de « lancés ». Elles reposent sur l’idée que la lumière est constituée de rayons qui vont partir de des sources lumineuses, se réfléchir, diffuser et réfracter sur les différentes surfaces (chaque surface pouvant renvoyer plusieurs rayons), puis atteindre la caméra. Dans les techniques de photon mapping, on part des sources lumineuses, on émet des rayons et on les suit jusqu’à la caméra (cette technique est décrite dans un autre article du blog de Simon et fera l’objet d’une traduction). Dans les techniques de lancé de rayons, on part de la caméra, on lance un rayon pour chaque pixel de l’image finale et l’on remonte jusqu’aux sources de lumière (illustration suivante).

(Source : Wikipédia – Raytracing)

Dans la technique du lancé de cônes (Cone Tracing), présentée dans l’article traduit, on remplace simplement les rayons par des cônes pour le calcul de l’illumination.

Occlusion ambiante

Cette technique fera également l’objet de plusieurs traductions du blog de Simon, je la détaillerai à ce moment là.

Simplement pour comprendre l’idée générale : lorsque deux surfaces sont proches (dans une fissure, un trou), la lumière indirecte diminue fortement et l’on observe des ombres douces. Plus les surfaces sont proches et fermées, plus l’ombrage sera important. L’illustration suivante représente la même scène sans (en haut) et avec l’occlusion ambiante (en bas). Remarquez en particulier l’ombre dans l’angle du mur et du sol et entre la sphère dans l’image du bas.

Cette technique améliore fortement la qualité du rendu et commence à être très utilisée dans les jeux. Un de ses points forts est que pour un objet statique (ou peu dynamique), l’occlusion ambiante ne varie pas (ou peu) et il est possible de la pré-calculer, le résultat étant mis dans une texture. Il suffit ensuite d’appliquer la texture sur l’objet lors du rendu, comme n’importe quelle autre texture.

Il existe plusieurs algorithmes de calcul de l’occlusion ambiante, mais pour comprendre le principe, voyons un exemple simple représenté dans l’illustration suivante. Pour chaque point d’une surface, on va lancer un nombre fixé de rayons qui vont parcourir une distance fixée aussi dans toutes les directions. On compte ensuite le nombre de rayons qui ne rencontrent pas une autre surface et on calcul le rapport entre le nombre de rayons ayant rencontrés une surface et le nombre de rayons lancés. Ainsi, dans l’illustration suivante, pour le point A, sur les six rayons lancés, aucun ne rencontre de surfaces, le rapport est de 0/6 = 0 %. Pour le point B, seul quatre rayons ne rencontrent pas de surfaces sur les six lancés, le rapport est de 4/6 = 66 %. Pour le point C, deux rayons ne rencontrent pas de surfaces, le rapport est de 2/6 = 33 %.

Il suffit ensuite d’atténuer la lumière pour chaque point en fonction du rapport calculé. Plus le rapport est proche de 0 %, plus la surface sera sombre et plus le rapport est proche de 100 %, plus la surface est claire.

Pour obtenir un bon rendu, on pourra augmenter le nombre de point et le nombre de rayons lancés, mais l’impact sur les performances sera important.

Partitionnement de l’espace

Voxel

Le principe des voxels est relativement simple : ils sont l’équivalent en 3D des pixels pour la 2D. Un exemple bien connu d’utilisation des voxels est le jeu Minecraft, dans lequel chaque élément (terrain, objets) sont représentés par des cubes.

(Source : Wikiépdia – Minecraft)

Les voxels sont particulièrement gourmand en termes de performances et sont encore peu utilisés pour les jeux vidéos. Ils sont particulièrement adaptés pour le rendu de volumes transparents (verre, liquide, fumée, nuage) ou de géométries très complexes (pour le rendu d’un mesh complexe, une approche utilisant une version low poly du mesh et une texture des Displacement/Normal/Bump mapping).

Octree

Un octree est une structure permettant de partitionner l’espace dans un arbre, permettant par exemple de faciliter la recherche d’un élément par rapport à sa position 3D. La construction d’un tel arbre est simple : à chaque itération, le cube représentant une partie de l’espace est divisé en 8 cubes.

(Source : GPU Gems 2 – Octree Textures on the GPU)

L’intérêt des octrees avec les voxels est que l’on va pouvoir utiliser une structure « creuse » : les zones qui sont vides ne seront pas divisées en cubes plus petits, simplifiant ainsi les algorithmes de recherche et la mémoire.

Un problème que l’on revoit souvent sur le forum est l’installation de Qt 5. J’ai réalisé, dans le cadre du livre sur Qt auquel je participe (Créer des applications avec Qt 5 – Les essentiels), plusieurs vidéos pour expliquer comment installer et tester l’installation.

Il y a quatre vidéos pour le moment :

• installation sur Windows avec Microsoft Visual C++ 2010 ;
• installation sur Windows avec MinGW ;
• installation sur Linux en utilisant les binaires ;
• installation sur Ubuntu en utilisant les dépôts.

Les vidéos sont disponibles sur le site de l’éditeur : D-booker.fr (YouTube).

Je n’ai pas fait de prise son, donc penser à activer les sous-titres pour avoir les explications. J’essaierais de proposer prochainement d’autres vidéos d’installation (sur Mac, sur Raspberry Pi) ou des démos.

Bonne visualisation (et bonne lecture à ceux qui liront le livre ;))

• utiliser deux boucles for imbriquées pour parcourir chaque pixel du widget et calculer la couleur correspondante, en faisant varier les paramètres S et V dans l’espace colorimétrique HSV ;
• utiliser deux gradient (à l’aide de la classe QLinearGradient), le premier, horizontal, allant du blanc à gauche à la teinte choisie à droite, et le second, vertical, allant du transparent en haut au noir en bas.

Je vais présenter ici comment implémenter un benchmark avec Qt pour tester la rapidité de ces différentes méthodes et présenter deux autres méthodes pour accélérer le rendu : l’accès direct au tampon mémoire contenant l’image finale et l’accélération matériel sur carte graphique.

Création du programme Benchmark

Qt offre différents outils facilitant la création de tests unitaires et de benchmarks, rassemblés dans le module QtTest. Différents tutoriels permettent de se familiariser progressivement avec ce module.

Benchmark.pro

Pour créer notre programme Benchmark, commençons par créer un fichier de projet Benchmark.pro. Ce fichier de projet contient les déclarations de base suivantes : la liste des modules utilisés (core, gui puisse que l’on teste les fonctions de dessin et testlib) et le nom et le type de binaire généré (une application Benchmark dans notre cas) :

On ajoute ensuite la liste des fichiers à inclure dans notre projet. On va simplement créer une classe Benchmark : on ajoute donc les fichiers d’en-tête et d’implémentation :

benchmark.h

La classe Benchmark hérite de QObject (pour pourvoir utiliser le système de signaux et slots) et contient deux slots privés, un pour chaque méthode que l’on souhaite tester. Ces slots seront automatiquement appelés à l’exécution du programme. A part cela, le contenu de la classe est minimaliste :

benchmark.cpp

Dans le fichier d’implémentation, on ajoute chaque méthode dans les slots correspondants :

Il faut également ajouter la macro QTEST_MAIN, qui crée une fonction main, qui aura pour fonction de créer une instance de la classe Benchmark et d’exécuter les slots privés :

Méthode des deux boucles for

Pour mesurer le temps d’exécution d’une méthode, on utilise la macro BENCHMARK. Le temps du reste du code contenu dans le slot mais en dehors du bloc précédent la macro n’est pas évalué. Pour vérifier que le code généré correctement les nuances de gris, on enregistre les images produites :

Méthode des deux gradients linéaires

Le code étant expliqué dans la solution de l’exercice, je n’entre pas dans le détail ici.

Résultat du benchmark

Lorsque le programme est exécuté, des messages sont générés automatiquement à chaque étape du processus. L’en-tête décrit simplement le nom du programme et les versions de QtTest et de Qt utilisées :

Le premier slot que lance le programme est un slot spécifique, initTestCase, généré par défaut et ne faisant rien. Ce slot permet, si on le souhaite, d’initialiser des objets pour l’ensemble du programme :

Vient ensuite les différents slots que l’on a créé. Le premier est hsvGradient. Lorsque le temps d’exécution du slots est trop petit, la mesure risque de ne pas être précise. Pour palier à cet inconvénient, le code contenu dans le bloc de code suivant la macro BENCHMARK peut être exécuté plusieurs fois, le temps indiqué correspondant au temps moyen mesuré. Ici, le slot hsvGradient a été exécuté deux fois et le temps moyen est de 47 millisecondes :

Pour le slot doubleLinearGradient, le code a été exécuté une seule fois et le temps mesuré est de 57 millisecondes. On voit donc ici que cette méthode est plus lente que la première version (sur le système testé ! C’est à dire Linux dans mon cas. Sous Windows ou Max OS X, il est possible que les résultats soient différents). Cette différence peut s’expliquer par le fait que la génération de deux gradients et la gestion de la transparence est plus lente que l’accès directe aux pixels, sur le système de rendu par défaut (le système Raster) :

Le programme exécute ensuite un slot pour libérer les ressources initialisées dans la fonction initTestCase :

Pour terminer, le programme indique le nombre de slot exécutés sans incident (passed), ceux qui ont échoué (failed) et ceux qui n’ont pas été exécutés (skipped) :

Rendu dans un tampon mémoire

Dans la première méthode, on utilise la fonction Qimage::setPixel pour modifier chaque pixel un par un. Cette méthode permet d’utiliser une interface sécurisée et simple. Malheureusement, les calculs (calcul de l’adresse mémoire correspondant au pixel, conversion de l’espace colorimétrique HSV en RGB) et tests effectués en interne (la position du pixel est bien dans l’image ? Les valeurs de la couleurs sont-elles correctes ?) peuvent ralentir fortement l’exécution.
Il est alors possible d’optimiser le rendu en accédant directement à la mémoire à l’aide de pointeurs : on créer un bloc mémoire de taille suffisante que l’on alloue à une image puis on accède à chaque octet un par un.

ATTENTION : ce type d’approche peut comporter certains risques : en cas d’erreur dans le code, il est possible que l’on écrive dans une zone mémoire qui ne correspond pas à l’image. Aucun test n’est effectué pour vérifier que le pointeur pointe vers une zone valide. L’application peut devenir instable. De plus, il est possible que le code ne soit pas portable et donne des résultats différents en fonction des systèmes d’exploitation utilisés (je l’ai testé uniquement sur Linux, pensez à bien enregistrer tous vos documents avant de lancer le programme sur un autre système:) ).

La première chose a faire est de créer une zone mémoire de taille suffisante : un pixel étant codé sur 32 bits (un octet par composante de la couleur et quatre composantes : rouge, vert, bleu et alpha), il faudra donc réserver un bloc mémoire de width * height * 4 pour contenir toute l’image :

Il n’est pas nécessaire d’initialiser chaque octet du bloc mémoire (avec memset par exemple) puisque l’algorithme utilisé garanti que chaque octet sera initialisé durant l’exécution de celui-ci.

Pour commencer, on crée un pointeur pointant vers le premier octet du bloc mémoire :

On utilise deux boucle for, comme dans la première méthode, pour parcourir chaque pixel (en fait, on parcourt le bloc mémoire linéairement, en « déplaçant » le pointeur octet par octet et non en accédant aux coordonnées (x, y) comme dans le cas d’une image) :

Les valeurs de composantes RGB sont calculés par la méthode présentée dans la version QML de la solution de l'exercice :

Ensuite, pour chaque composante, on affecte la valeur calculée (sous forme de uchar pour être sur qu'elle occupe bien à un octet en mémoire) à l'octet pointé par le pointeur (en dé-référençant celui-ci) puis on « avance » le pointeur d’un octet :

On fait de même pour les autres composantes :

Pour terminer, on enregistre l’image générée :

Résultat du benchmark

Les messages de sortie d’application générés par le slot drawInBuffer indique que cette méthode est plus rapide d’un facteur 10 que les deux autres méthodes, avec un temps d’exécution moyen de 3,9 millisecondes :

Optimisation de l’algorithme

Jusqu’à présent, nous avons simplement travailler sur l’implémentation pour optimiser le rendu des nuances de gris. Une autre approche consiste à travailler sur l’algorithme utilisé et d’essayer de diminuer les calculs effectués.
Quelque soit l’approche utilisée, il sera nécessaire de parcourir l’ensemble des pixels du widget, soit explicitement, comme dans le cas de la première méthode présentée, soit implicitement, comme dans le cas des deux QLinearGradient. On ne pourra donc pas optimiser cette partie (on peut au mieux éviter de parcourir plusieurs fois chaque pixel, comme on fait avec la méthode avec les deux QLinearGradient).
On peut remarquer que, dans chaque méthode présentée jusqu’ici, on travaille avec des nombres réels, ce qui n’est pas optimal. L’idéal serait de travailler qu’avec des nombres entiers, mieux gérés par les processeurs, et d’effectuer que des opérations élémentaires : addition, soustraction et multiplication.

Regardons en détail ce que l’on souhaite faire lorsque l’on parcourt un ligne pour une composante en particulier. La composante est une valeur entière allant de 0 à 255 (ou de 255 à 0) pour les pixels allant de 0 à N (avec N > 256 pour être sur d’afficher toutes les nuances). Il faut donc parcourir chaque pixel et incrémenter, quand c’est nécessaire, la composante. Si on représente cela avec un graphique 2D, on obtient :

avec x, l’index des pixels, et y, la composante de la couleur (source : Wikipédia).

Le lecteur averti aura compris l’idée sous-jacente : calculer la composante de la couleur revient à dessiner une ligne dans un espace (x, y) discret. Or, il existe un algorithme très performant pour réaliser cela : l’algorithme de Bresenham. Il suffit juste de remplacer y par la composante de la couleur. Le lecteur se reportera à l’article de Wikipédia pour l’explication du principe de cet algorithme.

L’implémentation de l’algorithme est assez triviale à partir du pseudo-code. On fera attention aux notations utilisées, qui correspondent au pseudo-code, c’est à dire que y1 correspondent à la composante de la couleur et non à la position verticale du pixel. La variable i est utilisée pour parcourir verticalement l’image dans une boucle for :

L'image générée est un gradient allant du noir au blanc :

Pour générer toutes les nuances, il va falloir imbriquer deux fois algorithme, le premier allant du blanc à la teinte choisie (première ligne de pixels) et le second allant de la teinte (pixel de la première ligne) au noir (pixel de la dernière ligne). Il faut également gérer chaque composante indépendamment.

Pour terminer, il est possible de combiner cette méthode avec la méthode utilisant un tampon mémoire. Le code est très proche du précédent.

Résultat du benchmark

La méthode utilisant l’algorithme amélioré permet de gagner un facteur 3 à 4 par rapport aux premières méthodes :

La version combinant les deux approches permet un gain de performance d’un facteur 4 par rapport à la méthode utilisant un tampon mémoire et un facteur 50 par rapport au premières méthodes :

Accélération matériel sur carte graphique

Pour réaliser le rendu des nuances de gris sur carte graphique, on utilise une classe dérivée de QGLWidget. Il suffit de dessiner un rectangle s’adaptant à la taille du widget, le reste du travail de rendu est réalisé dans le fragment shader : on calcule le rapport entre la position du pixel et la largeur du widget (passé en paramètre) pour calculer la nuance de gris correspondante :

Pour que le fragment shader soit appliqué sur chaque pixel du widget, il suffit de dessiner un quadrilatère sur la totalité de la surface :

Les différents paramètres utilisés dans le fragment shader sont définis à l’aide des fonctions uniformLocation et setUniformValue. Par exemple, pour mettre à jour la taille du widget :

Par contre, je n’ai pas réussit à utiliser les fonctions de benchmarks de Qt Test pour tester la rapidité du rendu par cette méthode. Pour pouvoir mesurer le temps, j’ai ajouté un calcul du nombre de FPS (frame par seconde) avec un simple compteur, incrémenté à chaque cycle et remis à zéro toutes les secondes :

Pour mettre à jour la widget, j’utilise un QTimer avec un délai de 0.

ATTENTION : Il en faut pas laisser le programme tourner trop longtemps avec cette méthode. Le programme tourne en boucle et utilise la carte graphique au maximum de ses capacités, ce qui augmente progressivement sa température. Personnellement, je n’ai pas pris le risque de tester si cela pouvait endommager la carte graphique.

Performances

J’ai réalisé le test sur un ordinateur portable équipé d’une carte Nvidia 8600M GT avec 512 Mo et un widget de 256 x 256 pixels. Avec cette configuration, les mesures donnent un FPS moyen de 5000 fps avec de pointes à 5200 fps, c’est à dire des temps de rendu de l’ordre de 0,2 millisecondes (soit 250 fois plus rapide que les premières versions).

Les sources

Télécharger les sources des benchmarks.

Télécharger les sources de la version OpenGL.

L’objet QML ColorPicker

L’objet ColorPicker permet d’afficher les nuances de gris d’une couleur et de sélectionner une nuance directement en cliquant dans l’item. Les composantes des couleurs sont manipulées directement puisqu’il n’est pas possible d’extraire les composantes d’une couleur donnée en QML.
La couleur principale est définie par les variables main_red, main_green et main_blue. La couleur sélectionnée est récupérée grâce aux variables selected_red, selected_green et selected_blue dans le contexte ColorPickerContext.

La taille de l’item est fixée à 256×256 :

Pour dessiner les nuances de gris, on va utiliser deux gradients linéaires :

• le premier, horizontal, va du blanc à la couleur principale ;
• le second, vertical, va du transparent au noir.

Pour créer les gradients, on commence par définir un rectangle ayant les mêmes dimensions et position que l’item :

On utilise ensuite l’objet gradient pour remplir le rectangle avec le dégradé. Par exemple pour le second gradient :

On obtient ainsi un gradient vertical allant du transparent au noir. Pour le premier gradient, il faut donc effectuer une rotation du rectangle de 90° après l’avoir correctement dimensionné et positionné :

Pour visualiser la position de la couleur sélectionnée, on va afficher un cercle entourant la dernière position connue. Cependant, dessiner un cercle en QML est un peu complexe (il faut créer des objets path pour dessiner des courbes quadratiques et constituer le cercle). Pour simplifier, on va afficher une image de taille 8×8 pixels représentant un cercle avec le fond transparent :

On crée un objet image en indiquant la source du fichier. Par défaut, la taille de l’image est celle du fichier chargé :

Par défaut, on souhaite que le curseur soit placé au centre de l’item. Pour cela, on utilise les variables x et y :

Pour déplacer, le curseur en fonction de la position de la souris, il faut pouvoir identifier cette image :

On pourra alors déplacer l’image en modifiant les variables x et y, en ajoutant le code suivant n’importe où dans notre item :

Pour terminer, il faut pouvoir récupérer les évènements souris survenant sur notre item. Cela est réalisé en créer un objet MouseArea de même dimension que l’item :

Il faut ensuite demander à cette MouseArea de récupérer les clics sur le bouton gauche de la souris :

On va réagir à deux types d’évènements : un clic sur le bouton gauche, qui déclenche un évènement de type onPressed, et le déplacement de la souris avec le bouton enfoncé, qui déclenche un évènement de type onPositionChanged.
Lors de ces évènements, on récupère la position de la souris grâce aux variables mouseX et mouseY que l’on affecte aux positions de l’image avec cursor.x et cursor.y. Cependant, il ne faut pas oublier que la position de cursor correspond au coin en haut à gauche de l’image alors que la souris correspond au centre de l’image. Il faut donc corriger en fonction des dimensions de l’image :

Pour terminer, après un changement de la couleur sélectionnée, il faut recalculer les variables selected_red, selected_green et selected_blue. Pour cela, on appelle un fonction JavaScript updateSelectedColor(), qu’il faudra créer :

Pour connaître la couleur sélectionnée, on ne dispose pas de fonction équivalente à Qimage::pixel(). Les seuls éléments que l’on dispose sont : la position (x, y) de la couleur sélectionnée dans le widget de taille (width, height) et les composantes RGB de la couleur principale.
Il faut donc calculer les composantes RGB de la couleur sélectionnée à partir de ces éléments et de la méthode utilisée pour dessiner l’item.

Lorsque l’on dessine le premier gradient, on va du blanc (1, 1, 1) à la couleur principale (R, G, B). Le rapport entre la position cursor.x et la largeur est équivalent au rapport entre la composante de la couleur principale et le blanc :

On obtient alors l’équivalence suivante :

{r – 1} over {X} ~ = ~ {R – 1} over {width} ~ = ~ pente de la droite

Alors :

r ~ = ~ 1 ~ + ~ (R-1) {X} over {width}

De même pour les autres composantes :

g ~ = ~ 1 ~ + ~ (G-1) {X} over {width} newline
b ~ = ~ 1 ~ + ~ (B-1) {X} over {width}

Lorsque l’on dessine le second gradient, on va du transparent (alpha = 0) au noir (0, 0, 0, 1). La couleur final s’écrit :

couleur finale ~ = ~ couleur initiale * (1 – alpha) ~ + ~ noir * alpha ~ = ~ couleur initiale * (1-alpha)

La transparence alpha est liée à la position cursor.y par :

alpha ~ = ~ {Y} over {height}

On obtient donc la formule suivante pour la composante rouge :

r’ ~ = ~ r * (1 – {Y} over {height} ) newline
r’ ~ = ~ (1 + (R-1) {X} over {width}) * (1 – {Y} over {height} )

De même pour les autres composantes :

g’ ~ = ~ (1 + (G-1) {X} over {width}) * (1 – {Y} over {height} ) newline
b’ ~ = ~ (1 + (B-1) {X} over {width}) * (1 – {Y} over {height} )

La fonction JavaScript s’écrit alors, en utilisant ces formules :

La classe GradientWidget

Pour utiliser cet item QML dans du code C++, il est nécessaire d’écrire un wrapper pour récupérer les signaux et slots de l’item. Cette classe n’est pas un widget et dérive donc de QObject (pour pouvoir utiliser le système de signaux et slots) :

Pour récupérer la couleur sélectionnée, il faut créer une variable pour chaque composante et utiliser la macro Q_PROPERTY pour la rendre accessible en QML. Il faut également définir les fonctions d’écriture (pour modifier la variable depuis le QML) et de lecture (pour lire la variable à l’extérieur de la classe) :

Après avoir mis à jour la couleur avec la fonction setSelectedColor(), il faut émettre un signal contenant la couleur créée à partir des composantes :

Il faut également définir les variables et fonctions pour les deux autres composantes :

La création de l’item ColorPicker est réalisée dans le constructeur de la classe :

Dans ce constructeur, il faut créer un objet QDeclarativeView pour afficher l’item QML puis fournir le code QML à l’aide la fonction setSource. La taille est fixée à 256×256, comme dans le code QML. Dans cet exemple, le code QML est fournit dans un fichier .qml et référencé dans un fichier ressource .qrc :

Pour permettre au code QML de transmettre les variables contenant les composantes de la couleur sélectionnée, il faut récupérer le contexte par défaut de la vue et définir une propriété ColorPickerContext dans celui-ci. Cette propriété permet d’accéder à l’objet dans le code QML à partir de la variable ColorPickerContext et permettre ainsi d’accéder aux propriétés définies ci-dessus :

Les variables view et context sont définies dans l’en-tête de la classe par :

Lors de la création de l’item, on attribue également une couleur principale par défaut à l’aide de la fonction setMainColor() :

Cette fonction setMainColor() est un slot ayant un paramètre, la couleur a attribuer :

Pour transmettre cette couleur au code QML, on utilise la fonction setContextProperty(), qui permet d’attribuer une valeur à une variable QML :

Pour terminer, il faut créer les fonctions show() et move() pour pouvoir afficher et déplacer la vue :

Le résultat final

Voici le rendu obtenu :

Télécharger les sources de cet article.

Conception

Le widget devra simplement afficher un fond (les nuances de gris d’une couleur) et gérer les évènements de la souris (clique et déplacement pour sélectionner une nuance de gris).

Il est possible de partir de plusieurs classes différentes pour créer le nouveau widget. Voyons les avantages et inconvénients de chacune :

1. QWidget est la classe parent de tous les widgets de Qt. Elle fournit l’interface de base commune de tous les objets visibles. Par défaut, elle n’affiche rien et ne fait rien.
2. QScrollArea est destinée à afficher le contenu d’un widget dans un autre, en gérant les barres de déplacement horizontale et verticale. Dans cet exercice, la présence de barre de déplacement n’est pas souhaitée et il est préférable d’ajuster la taille de la zone de dessin à la taille du widget.
3. QLabel permet d’afficher un texte ou une image sans interaction avec l’utilisateur. Même s’il est possible de surcharger les fonctions de gestion des évènements souris, utiliser cette classe pour créer noter widget revient à ne pas respecter la conception de QLabel.
4. QpushButton permet également d’afficher des images mais gère aussi les évènements souris. Mais cette classe n’est pas destiner à gérer la position précise des évènements souris et de réagir différemment en fonction de celle-ci.

Au final, même si certaine classe présentent des fonctionnalités qui seraient intéressantes (affichage d’images, gestion des clics), seule l’utilisation de QWidget respecte la conception des objets Qt.

En partant de QWidget, quels seront les fonctions qu’il faudra implémenter ?

1. L’affichage des nuances de gris sera réalisée dans la fonction paintEvent(), qui prend en charge le dessin du widget. Il suffit de dessiner les nuances de gris puis la position de la couleur sélectionnée par un petit cercle.
2. La création des nuances de gris peut être réalisée directement dans paintEvent(). Cependant, cela implique de redessiner l’image à chaque déplacement de la souris, ce qui peut rendre le widget non fluide. De plus, la récupération de la couleur sélectionnée utilisera la fonction QImage::pixel(). Au final, il est donc préférable de dessiner les nuances de gris dans une QImage et d’afficher cette QImage dans la fonction paintEvent(). Cette image sera recalculée que lors d’un changement de la couleur principale ou lors du redimensionnement du widget.
3. La fonction resizeEvent() sera utilisée pour mettre à jour l’image contenant les nuances de gris.
   Les évènements souris seront gérés par les fonctions mousePressEvent(), mouseMoveEvent() et mouseReleaseEvent().
4. Le changement de couleur principale et la sélection d’une couleur utilisera le système de signaux et slots, pour faciliter l’interaction entre les widgets.

Pour dessiner les différentes nuances de gris d’un couleur, deux méthodes sont envisageables :

1. Dessiner deux gradients superposés : un premier gradient linéaire, horizontal, allant du blanc (à gauche) à la couleur principale (à droite) ; un second gradient linéaire, horizontal, allant du transparent (en haut) au noir (en bas).
2. Faire varier les composantes S (saturation) et V (valeur) d’une couleur en fonction des coordonnées (x, y) d’un pixel. La saturation permet d’aller du blanc (S=0) à la couleur (S=255) et correspond donc à l’axe horizontal. La valeur permet d’aller du noir (V=0) à la couleur (V=255) et correspond donc à l’axe vertical.

Ces deux méthodes sont identique visuellement (mais présentent en réalité des petites différences) et permettent toute deux d’afficher toutes les nuances de gris d’une couleur.

Interface

Pour créer l’interface de notre classe, on crée une classe GradientWidget héritant de Qwidget, avec son constructeur :

Les fonctions de gestion des évènements surchargent les fonctions de même nom de QWidget :

La connexion avec les autres widgets est assurée par le signal envoyé lors de la sélection d’une couleur et le slot reçu lors du changement de couleur principale :

Les variables privées permettent de conserver les couleurs principale et sélectionnée, l’image dans laquelle on dessine les nuances de gris, la position du curseur et une variable boolean indiquant si la mouvement de la souris correspond à un clic ou non :

Les variab Pour finir, deux fonctions privées, permettant de redessiner les nuances de gris et de mettre à jour la couleur sélectionnée :

Implémentation

Commençons par l’implémentation de la fonction updateSelectedColor(). Celle-ci récupère simplement la couleur du pixel de m_gradient_image à la position m_cursor_position, émet le signal colorSelected() puis appelle la fonction update() pour mettre ajour le widget :

Création des nuances avec QLinearGradient

La première version de la fonction updateGradientImage() utilise l’approche à deux gradients :

On crée une QPixmap de la taille du widget puis un QPainter pour dessiner dedans. Par défaut, nous n’avons pas besoin de dessiner des traits donc on supprime le QPen :

Pour dessiner des gradients linéaires, Qt propose une classe QLinearGradient. Il suffit donc de préciser les positions des points du gradient et les couleurs de ces points. Pour le premier gradient, les couleurs doivent aller du blanc (Qt::white) à la position (0, 0) à la couleur m_main_color à la position (with, 0) :

Puis on dessine un rectangle de la taille du widget :

Pour le second gradient, les couleurs doivent aller du transparent (Qt::transparent) à la position (0, 0) au noir (Qt::black) couleur m_main_color à la position (0, height) :

On convertit ensuite la Qpixmap en Qimage et on la conserve dans m_gradient_image :

Pour finir, puisse que le gradient à été mis à jour, on met également à jour la couleur sélectionnée :

Création des nuances avec HSV

La seconde version de updateGradientImage() utilise deux boucles imbriquées qui parcourent l’ensemble des pixels de l’image et qui calcul la couleur en faisant varier la saturation et la valeur en fonction de la position (x, y). Pour commencer, il faut redimensionner l’image de destination si celle-ci n’est pas identique aux dimensions du widget :

La teinte est obtenue à partir de la couleur principale :

On parcourt l’ensemble des pixels de l’image à l’aide de deux boucles imbriquées :

Il reste plus qu’a dessiner un cercle à la position m_cursor_position :

Le diamètre du cercle est une constante définie en début du fichier d’implémentation :

Lors d’un évènement souris de type mousePressEvent, on teste si l’utilisateur a cliqué sur le bouton gauche :

Si c’est le cas, on active le suivi des mouvements de la souris, on récupère la positon de la souris dans m_cursor_position puis on met à jour la couleur sélectionnée :

Lors d’un évènement de type mouseReleaseEvent, on déssactive le suivi de la souris et on met à jour la couleur sélectionnée :

Les mouvements de la souris sont détectés par l’évènement mouseMoveEvent. Pour que ces événements soient pris en compte pour le widget, il faut les activer en utilisant la fonction setMouseTracking(true) dans le constructeur. Ces évènements mouseMoveEvent sont activés même lorsqu’aucun bouton n’est appuyé. C’est la fonction de la variable m_tracking d’indiquer si on déplace la souris en conservant un bouton cliqué ou non.
Lorsque l’on maintient appuyé un bouton de la souris et que l’on déplace celle-ci en dehors du widget, des évènements mouseMoveEvent continuent d’être envoyé. Si on prend en compte ces évènements, on risque de demander la couleur de pixels en dehors de la taille de m_gradient_image, ce qui provoquera des erreurs. Il faut donc tester si la position de la souris est dans le widget. Au final, le code de mouseMoveEvent sera :

Lors d’un changement de taille du widget, il suffit de remettre à jour le gradient :

Il ne reste plus qu’a implémenter le constructeur :

Ainsi que le slot setMainColor() :

Le résultat final

Voici le rendu obtenu :

Télécharger les sources de cet article.

Première partie : créer une zone de sélection avec gradient

Bonjour à tous,

Nous savons que vous attendez avec impatience le prochain défi Qt, cependant un défi de qualité prends du temps à organiser et mettre en place. Pour palier à votre envie de développer et de vous faire les dents sur un nouveau projet, nous vous proposons un nouveau concept : les exercices Qt.

Le principe

Des petits sujets réguliers pour lesquels vous pouvez apporter une solution en détaillant quelques étapes clés imposés. La durée de l’exercice dépendra de la difficulté de l’énoncé. Il est possible qu’un sujet conséquent en travail soit proposé et ainsi découpé en plusieurs parties représentant une suite d’exercices sur le même thème.

Tout le monde peut ainsi proposer une solution pour répondre à l’exercice posé. Dans le cas d’un exercice en plusieurs parties, la meilleure solution pourra être utilisée par les autres participants pour la suite de l’exercice.

Il est impossible pour l’équipe de réunir un jury et réaliser un barème aussi poussé que celui des défis Qt. La meilleure solution sera ainsi désignée d’un point de vue plus subjectif que pour les défis Qt par les responsables de la rubrique Qt, à savoir dourouc05 et moi-même et éventuellement d’autres membres de l’équipe Qt en fonction des disponibilités de chacun.

Les exercices seront ainsi proposés le vendredi (vous permettant d’y travailler dès le week end après avoir découvert le nouveau sujet). La fin du dépôt des propositions aura lieu le vendredi soir à 23h59, un certain nombre de semaines (dépendant de la difficulté de celui-ci) après la présentation du sujet et le vainqueur sera désigné dans la semaine suivante avant la proposition du nouvel exercice.

Nous essayerons de faire attention à ce qu’il n’y ait pas de copie entre les codes des participants en appliquant la règle que le premier code publié sur le forum « appartient » au membre l’ayant posté. Il existe bien sur des réponses à ces solutions sur internet, mais quel est l’intérêt pour vous de les utiliser ?

Le premier sujet !

Le thème

Ce premier exercice fait parti d’un thème qui est la réalisation d’un color picker. Ci-dessous, quelques color pickers connus mais libre à vous de faire travailler votre imagination pour nous donner une meilleure solution au final :

Ce thème est découpé en trois parties qui toutes durent deux semaines. Un nouvel énoncé d’exercice sera donc publié toutes les trois semaines (en comptant la semaine de correction).

Première partie : widget personnalisé pour affiche et sélectionner la nuance de gris d’une couleur

Création d’un widget permettant de sélectionner la nuance de gris à partir d’une couleur. Seul le widget affichant le gradient de la nuance de gris sur une couleur sera évalué mais votre fenêtre peut afficher la couleur en cours et les valeurs de celle-ci pour démontrer le bon fonctionnement de celui-ci.

Le widget peut être carré, rectangulaire, sphérique, en cercle, libre à votre imagination.

Les étapes d’explications imposées :

1. Mise en place de la structure du widget (héritage, composition…) ;
2. Réalisation du gradient ;
3. Sélection et récupération de la couleur à partir du gradient.

Vous avez donc jusqu’au vendredi 3 septembre 23h59 pour nous fournir une solution. Le dépôt des solutions ce fait sur le forum à la suite de ce message.

J’espère que l’idée vous plait, n’hésitez pas également à nous faire part de votre participation à la suite de ce message, de présenter votre solution en avant première et je finirai par dire : à vos claviers !

Seconde partie : accompagner le widget d’un sélecteur de couleur et amélioration de celui-ci

L’objectif est de continuer le widget en l’améliorant et ajoutant d’autres fonctionnalités. Pour ceux qui n’auraient pas un widget fonctionnel, voici une archive contenant la classe du widget du vainqueur de la première partie à savoir gbdivers, améliorée par mes soins pour prendre en compte les malus qui lui ont été mis à la correction !

La première amélioration requise pour la partie deux est la création d’un slider permettant la création de la couleur principale (teinte ou hue en anglais). L’image ci-jointe vous montre de quoi je parle :

Ce slider peut faire partie du widget ou être un widget indépendant. Je vous conseille de regarder la classe QSlider et les paramètres pour la personnalisée.

De plus un ensemble de champ QLineEdit respectant un certain format QIntValidator devra permettre d’afficher et de modifier la valeur de la teinte, saturation ou valeur. En cas de modification, le changement se répercutera sur le widget par le déplacement du point de sélection. Il existe donc une connexion dans les deux sens entre ces différents éléments.

Par la suite, il faudra modifier le widget existant pour permettre également d’afficher les dégradés de la saturation et de la valeur (et non plus la teinte, hue en anglais).

Exemples :

C’est tout pour les étapes imposées dans cette seconde partie qui durera deux semaines.

Pour les personnes qui ont de l’avance, vous pouvez réfléchir à n’afficher que les couleurs disponibles pour le web et la représentation des dégradés dans les autres espaces colorimétriques.

Si vous avez besoin d’explications supplémentaires, n’hésitez pas à poser des questions à la suite de ce message. De plus la correction et le code source de l’ensemble des candidats pour la première partie est disponible dans ce sujet.

Bon courage !

Vous pouvez commenter cet article sur le forum.

Complexité du langage ou de l’apprentissage

Cette partie a été écrite par JolyLoic.

Lorsque l’on compare différents langages, il existe plusieurs notions de complexité, dont la confusion est une des causes qui fait que ces comparaisons s’enflamment.

Il y a au moins :

• la complexité intrinsèque d’un langage, celle qui correspond à l’effort à réaliser pour y devenir un gourou qui connait tous les détails les plus arcanes. Cette complexité peut quasiment se mesurer au nombre de pages d’un document décrivant le langage. Sur ce plan, le C++ est beaucoup plus complexe que le C, c’est indéniable ;
• la complexité au jour le jour d’un langage, qui est liée au niveau de discipline mentale nécessaire pour coder, ainsi qu’à la puissance des abstractions que l’utilisateur peut mettre en œuvre pour l’aider. Je suis convaincu que sur ce plan, le C++ est beaucoup plus simple que le C ;
• la complexité d’apprentissage. Elle correspond à la difficulté du parcours d’un étudiant ne connaissant rien et devant apprendre assez du langage pour en devenir professionnel. Je pense là aussi que le C++ et plus simple que le C, mais la réponse est moins tranchée.

La complexité intrinsèque et la complexité au jour le jour sont bien évidemment en opposition, puisque si l’on complexifie un langage, ce n’est pas par pur plaisir masochiste, mais bien pour le rendre plus puissant, donc plus efficace au jour le jour. La complexité d’apprentissage est liée aux deux autres, mais aussi à la notion de progressivité.

Cette notion de progressivité de l’apprentissage me semble importante. À part à un haut niveau post-bac, où l’on suppose les étudiants comme des experts dans l’art d’ingurgiter des connaissances (et où à mon avis, on se trompe de méthode, mais c’est un autre sujet), l’ordre d’apprentissage n’a rien à voir avec un ordre logique, qui irait du plus théorique au plus pratique (ce qui consisterait pour notre langue maternelle à faire de la linguistique, de la grammaire et à apprendre le dictionnaire dans l’ordre, avant de dire papa-maman, et dans le programmation à préconiser l’apprentissage du théorème du point fixe, du lambda calculus et autres modélisations mathématiques des langages avant de faire un hello world), ou encore, pour parler d’informatique du plus proche du matériel au plus éloigné (qui consisterait à faire de l’électronique, puis de l’assembleur, puis du C puis du C++).

Non, l’apprentissage se fait de manière pragmatique, en parcourant le sujet à enseigner de manière en apparence erratique, mais avec pour objectifs :

• que chaque pas ne soit pas trop gros, afin de ne perdre personne ;
• que le parcours soit à chaque étape intéressant, afin de motiver les gens.

Un des points de passage de plus haute complexité du C comme du C++ est la notion de pointeurs, avec ses corollaires d’allocation dynamique de la mémoire (mais même sans ça, la notion de pointeur et de valeur pointée pose bien des problèmes). Or, en C, impossible d’écrire un programme un minimum intéressant sans utiliser explicitement des pointeurs. En C++ (ou des d’autres langages comme java ou C#), l’utilisation de ces pointeurs peut être cachée pendant assez longtemps et on a donc bien plus de liberté pour choisir un parcours le long duquel la courbe d’apprentissage ne présente pas de murs trop importants.

Apprentissage d’un langage ou de la programmation

Avant d’expliquer et critiquer les phrases indiquées dans l’introduction, il convient de préciser quel est l’objectif recherché dans l’apprentissage. Si l’on est dans le cadre de l’apprentissage d’un langage précis, par exemple dans le cadre d’un cours scolaire, dans lequel le langage à utiliser est imposé, alors bien évidemment, la question de savoir si le C++ est plus adapté pour les débutants n’a pas lieu d’être. Nous nous placeront donc dans le cas où la personne qui souhaite apprendre le C ou le C++ est libre de son choix.

Quelle est la différence entre apprendre un langage et apprendre la programmation ? Dans le premier cas, l’attention se porte sur l’apprentissage de la syntaxe du langage, ce que l’on fait de ce langage compte peu finalement. Dans le second cas, l’objectif est de savoir concevoir efficacement un programme permettant de répondre à une problématique donnée. Que ce soit dans le cadre amateur ou professionnel, ce dernier objectif est beaucoup plus intéressant et c’est dans cette optique que se place ce billet de blog.

Précisons ce que signifie ce que l’on entend par « efficacement ». Dans la création d’un programme, on pense en général à la phase de codage et l’on comprend facilement qu’entre deux langages, si le premier permet d’obtenir le même résultat que le second, mais en utilisant 10 fois moins de lignes de code, alors il sera beaucoup plus efficace d’écrire un programme dans ce langage. Cependant, la création d’une application ne se limite pas à écrire du code et l’expérience montre que l’on passe beaucoup de temps sur d’autres tâches : la conception du programme, la correction des bugs, la validation du programme (vérifier que le programme donne le résultat correct). Le terme « efficacement » doit donc être considéré en analysant le temps global de développement et pas simplement la phase de codage.

Conception impérative et objet

La comparaison entre les différents paradigmes de programmation, leurs intérêts et inconvénients respectifs, leurs efficacités, n’est pas le propos de cet article, je ne vais donc pas m’attarder sur ce point. Signalons simplement que la raison même de la création de la programmation objet est de faciliter la création d’application, on peut s’attendre à ce que la conception en C++ utilisant des objets (correctement…) sera plus efficace qu’en C.

Erreurs à la compilation et l’exécution

Problématique

Probablement tous les développeurs expérimentés ont déjà eu le problème suivant, d’un bug dont l’origine était indéterminée et qui a nécessité plusieurs heures de recherche pour le corriger. Partant de ce constat, on peut tirer la règle suivante : plus la détection des erreurs est précoce, plus il sera facile de les corriger. Autrement dit, les erreurs survenant à la compilation seront beaucoup plus simples à corriger que les erreurs survenant lors de l’exécution (et l’une des forces des templates en C++ est de pouvoir justement réaliser beaucoup de vérifications à la compilation, sans surcoût à l’exécution, mais cela sort du sujet de ce blog).

Pour être plus concret, voyons un exemple avec la vérification de la constance des variables (« const-correctness »). Le mot-clé const, utilisé pour le passage de paramètres dans les fonctions, est un contrat que passe l’utilisateur d’une fonction avec le créateur de cette fonction. Il permet de dire : cette variable ne sera pas modifiée dans cette fonction.

En théorie…

Voyons ce que cela donne en pratique. Imaginons une fonction foo() prenant une chaîne de caractères constante et pouvant modifier cette chaîne. Le respect de cette constance implique donc que la fonction ne doit pas travailler sur la chaîne passée en argument de la fonction (potentiellement non modifiable), mais sur une copie modifiable de cette chaîne.

Cas du C

Voyons par exemple le code suivant, qui convertit un simple const char* en char* (donc qui supprime le mot-clé const) :

Lorsque l’on compile avec un compilateur C, celui-ci ne donne qu’un simple avertissement sur le fait que l’on modifie une variable constante en non constante. Malheureusement, les warnings sont souvent ignorés par les débutants et le code ne sera pas corrigé. C’est une mauvaise pratique largement répandue et c’est souvent une bonne chose d’activer l’option -Werror dans gcc, pour que les warnings deviennent des erreurs). On va pouvoir observer des comportements différents en fonction du code de bar(). Si la fonction bar() ne modifie pas la chaîne, par exemple avec le code suivant, alors il n’y aura pas de problème, le programme s’exécutera sans erreur :

En revanche, si la fonction bar() modifie la chaîne, on va obtenir une erreur à l’exécution. Par exemple, le code suivant :

Ce code va générer l’erreur suivante :

Ce message d’erreur ne nous apprend pas grand-chose. Il indique simplement qu’il y a un problème d’accès sur une mémoire invalide, mais n’indique pas que l’on ne respecte pas le const-correctness et ne précise pas la ligne de code où se situe le problème. On imagine bien alors que dans un programme contenant plusieurs milliers de lignes de code, il sera difficile de trouver l’erreur.

Même si le premier code de bar() ne provoque pas d’erreur à l’exécution, il n’en reste pas moins que le code de foo() est la source du problème. Cependant, il n’y a pas de validation réalisée par le compilateur et il est facilement possible dans ces conditions d’avoir du code potentiellement problématique qui fonctionne… quelques temps. Et à l’occasion d’une modification mineure, ce code problématique va déclencher une erreur d’exécution et la recherche de l’erreur sera fastidieuse. On dit souvent, de façon humoristique, qu’un code problématique et qui fonctionne quand même « que le programme tombe en marche ».

Sans cette vérification à la compilation, il est facile de se tromper, par exemple en écrivant le nom des fonctions. Supposons que l’on a deux fonctions, une version qui ne modifie pas la chaîne et utilise donc directement la chaîne passée en argument ; une version qui modifie la chaîne, par exemple en appelant realloc(). Normalement, il faudrait récupérer le pointeur retourné par la fonction, mais comme on appelle la mauvaise fonction, on oublie de le faire :

En C, lors de la compilation, il y aura un simple warning, qui est facilement manqué. À l’exécution, le message d’erreur n’indique pas l’origine du problème. Plus que le fait que le code à écrire est plus long qu’en C++, il y aura une perte de temps très importante, plusieurs heures voir plusieurs jours, pour trouver l’origine des erreurs.

Cas du C++

En C++, la situation sera beaucoup plus simple : ce code génère une erreur suivante, indiquant que l’on essaie de convertir une variable constante en variable non constante :

L’erreur est simple (profitons-en, ce n’est pas toujours le cas en C++) et parfaitement localisée, la correction du code sera directe et rapide.

Détection des fuites mémoires

Problématique

Commençons par un rappel : qu’est-ce qu’une fuite mémoire ? Lorsque l’on alloue une variable dynamique sur le Tas, le bloc mémoire alloué doit être détruit à un moment donné, quand on en a plus besoin, pour éviter de saturer la mémoire disponible. L’adresse mémoire est sauvegardée dans un pointeur et il suffit d’appeler la fonction adéquate pour libérer la mémoire, en fonction de la fonction utilisée pour l’allouer : free() avec malloc ou calloc, delete avec new, delete[] avec new[]. Une fuite mémoire survient lorsque cette libération n’est pas réalisée, par exemple si on perd le pointeur, si on n’appelle pas la fonction de libération adéquate, voir qu’on appelle pas du tout cette fonction.

La difficulté avec les fuites mémoires est que c’est un problème qui survient exclusivement à l’exécution, on retombe sur le souci décrit dans le chapitre précédent : la localisation pourra être complexe et longue. Il existe des outils d’analyse des allocations, tel que valgrind, qui permet de rechercher ce type de problème (et il est recommandé de l’utiliser régulièrement), mais s’il est possible de minimiser les risques lors de la phase de codage, cela pourra améliorer l’efficacité.

Cas du C

Revenons sur le code précédent de foo() et corrigeons le problème de const-correctness en copiant la chaîne constante dans une nouvelle chaîne non constante. Pour simplifier le code, il est possible d’écrire deux fonctions d’aide pour gérer la mémoire : createString(), pour allouer la mémoire et copier la chaîne, et destroyString(), pour libérer la mémoire. Une implémentation de ces fonctions peut-être la suivante :

Le code de la fonction foo() est modifié de la façon suivante :

Dans un code aussi simple, il est peu probable que le développeur oublie de libérer la mémoire à la fin de la fonction foo(). Par contre, dans une situation plus complexe, dans lequel la création de la chaîne est réalisée à un endroit du programme, l’utilisation à d’autres endroits et la libération encore ailleurs, il peut être difficile de savoir si la mémoire est correctement libérée.

De plus, le code précédent n’apporte pas de garanties fortes sur la libération. Par exemple, si le code entre createString() et destroyString() contient des return, la fonction destroy() ne sera pas appelée. Il est de la responsabilité du développeur de penser à appeler destroy() avant chaque return, ce qui peut être facilement oublié. Si la fonction manipule plusieurs objets dynamiques, il faut savoir à tout moment quelles sont les variables allouées et celles qui ne le sont pas.

Plus pernicieux, le code peut allouer un nouveau bloc mémoire et attribuer l’adresse dans un pointeur, ce qui invalidera celui-ci et provoquera une fuite.

En général, on trouve deux profils sur le forum : ceux qui croient qui ne feront jamais d’erreurs aussi grossières et ceux qui savent qu’il peut arriver de faire de telles erreurs. En général aussi, les premiers viennent sur le forum parce qu’ils ont des problèmes avec leur code, les seconds viennent pour aider les premiers.
Choisissez votre camp. Et si vous faites partie du premier groupe, posez-vous peut être des questions…

Cas du C++

La situation pourrait sembler plus compliquée en C++. En effet, le C++ ajoute un système de gestion d’erreurs, absent du C : les exceptions. Ce système peut briser l’ordre séquentiel d’exécution du code et il peut être difficile de garantir la robustesse du code.

Cependant, le C++ propose également un système qui permet de transférer la responsabilité de la libération de la mémoire. En effet, grâce au RAII (acquisition de ressources à l’initialisation), la libération est sous la responsabilité d’une classe au lieu d’être sous celle de l’utilisateur. Le RAII est un principe qui peut être implémenté par les concepteurs d’une classe utilisant des ressources dynamiques, mais pour simplifier le travail, la bibliothèque standard STL fournit déjà de nombreuses classes encapsulant le RAII : std::string pour les chaînes, std::vector pour les tableaux, std::shared_ptr pour les pointeurs, etc.

Voyons par exemple une fonction utilisant une chaîne de caractères en C++ :

Ce code, en plus du fait d’être beaucoup plus simple, nous garantit que quelles que soient les lignes de code contenues dans la fonction, la chaîne de caractères str sera correctement libérée lorsque l’on sort de la fonction et quelle que soit la façon dont on sort de cette fonction (par return, par exception). L’attention du développeur peut se focaliser sur le problème à résoudre et plus sur les détails de gestion de la mémoire.

Conclusion

D’autres arguments peuvent être abordés pour justifier l’apprentissage du C avant le C++ (on parle de l’approche historique de l’apprentissage du C++), mais une analyse peut facilement les mettre à mal. Par exemple, l’argument selon lequel l’apprentissage bas-niveau en C permet de mieux comprendre ensuite la programmation plus haut-niveau en C++. Outre le fait que l’apprentissage de la gestion manuelle de la mémoire n’est pas un prérequis pour comprendre les notions d’allocation dynamique, de Pile et de Tas, la pratique montre que ceux qui abordent l’apprentissage par cette approche se perdent dans les détails et le débogage et ont plus de mal à assimiler les concepts plus haut-niveau (conception objet, encapsulation, principes de programmations objet, etc.)

On pourrait croire que mes propos sont exagérés, qu’il est rare de faire des erreurs aussi grossières, que cela n’empêche pas de comprendre les concepts de programmation objet. En pratique, on voit régulièrement sur le forum les étudiants faire les mêmes erreurs d’apprentissage (un exemple récent), mais ce n’est pas une fatalité et il est possible de corriger notre façon d’enseigner la programmation en C++.

Remerciements

Merci à JolyLoic pour la partie qu’il a rédigée et ses remarques, à Winjerome, Kalith et LittleWhite pour leur relecture et leurs remarques, à Winjerome pour ses corrections orthographiques.

Les modules Essentials

Le module Qt Core

Ce module fournit les fonctionnalités de base de Qt, excepté ce qui concerne l’interface graphique. Tous les autres modules sont liés à ce module. Voici la liste de quelques ajouts dans Qt 5 :

• QStandardPaths : permet de récupérer les répertoires par défaut en fonction de la plateforme. C’est une évolution de QDesktopServices avec plus de fonctionnalités, sur le modèle de KStandardDirs de KDE. Cela permet par exemple de faire une recherche de toutes les occurrences d’un fichier dans les différents répertoires ;
• support de JSON : permet de créer ou de lire un fichier JSON à partir d’une représentation binaire en mémoire ;
• extension prise en charge MIME : permet de déterminer le type mime d’un fichier ou de données en mémoire, en fonction de l’extension et/ou du contenu. Ce module utilise une base de données des types MIME par QMimeDatabase fourni par freedesktop.org shared-mime-info project. Cette base de données est incluse par défaut dans le système sous Linux et fourni par Qt sur Windows et Mac OS X ;
• vérification des connexions signaux/slots à la compilation : vérifie l’existence du signal et du receveur et que les arguments sont compatibles. Cette fonctionnalité utilise les templates et est compatible avec C++11. Il est possible de connecter un signal à des fonctions lambda, des fonctions membres ou des fonctions statiques, sans avoir besoin de déclarer comme slots. Voir l’article détaillé sur le sujet : Les signaux et slots dans Qt 5 ;
• QRegularExpression : nouveau moteur d’expressions régulières compatible Perl, plus puissante et rapide que QRegExp, avec plus de fonctionnalités (lazy and possessive quantifiers, lookbehinds, named capturing groups and iteration of matches) ;
• amélioration des performances, en particulier pour les structures de données ;
• amélioration du support C++11 quand c’est possible (mais compatibilité avec C++98) ;
• support des boutons supplémentaires sur les souris (souris pour joueurs), jusque 27 boutons pour XCB, XLIB ou DirectFB, jusque 16 pour Wayland, Evdev ou OS-X, jusque 8 pour BlackBerry/QNX et 5 sur Windows (limitation due au système).

Le module Qt Gui

Ce module fournit les fonctionnalités de base pour créer une interface utilisateur. Les anciennes classes QWidget et dérivées sont séparées dans un module indépendant. Ce module contient de nouvelles classes comme QWindow, QScreen, QSurfaceFormat permettant le support de fonctionnalités de base et est surtout destiné à être utilisé par les autres modules (QWidget, QQuickView, Qt 3D View, etc.).
En particulier, ce module fournit les classes QOpenGLxxx (QOpenGLFramebufferObject, QOpenGLShaderProgram, QOpenGLFunctions, QOpenGLContext, etc.) permettant de fournir l’accélération matérielle pour tous les modules graphiques (widgets traditionnels, Qt Quick). La classe QOpenGLContext est plus générique que QGLContext et est découplée de QWindow, pour permettre d’utiliser un contexte commun pour plusieurs affichages. QOpenGLPaintDevice permet d’utiliser directement QPainter sur un contexte OpenGL sans devoir dériver de QWindow ou QOpenGLFramebufferObject.
Voir l’article OpenGL dans Qt 5 pour plus de détails.

Le module Qt QML

Ce module permet d’utiliser le langage de script déclaratif QML grâce au QML engine. Il présente des améliorations des performances et des ajouts de fonctionnalités par rapport celui inclus dans Qt 4.

Le module Qt Js backend (JavaScript)

Ce module fournit un interpréteur JavaScript, permettant de scripter les applications écrites en C++ et en QML. Il utilise un nouveau moteur JS v8 plus rapide. Il inclut de nouvelles classes (QJSEngine, QJSValue), le support de nouveaux types (QColor avec les propriétés r, g, b et a, QVector4D constructible avec Qt.vector4d()). Il est possible d’ajouter des fonctionnalités dans un namespace avec la fonction qmlRegisterModuleApi et d’importer du QML et du JS directement dans un fichier JS.

Le module Qt Quick

Ce module permet de créer des interfaces dynamiques riches, en utilisant les modules QML et le JS. Cette nouvelle version de Qt Quick correspond au module « qtquick2″ alors que l’ancienne version correspond au module « qtquick1″. L’interface graphique de Qt Quick 2 se base maintenant sur scenegraph et permet l’accélération matérielle en utilisant les classes QOpenGLxxx de Qt Gui.
On trouve de nouvelles classes (QQuickView, QQuickCanvas, QQuickItem et QQuickPaintedItem qui remplacent les classes équivalentes de QDeclarative), de nouveaux items (Canvas permet le support de l’API Context2D de HTML 5, le rendu est réalisé dans Canvas.Image et Canvas.FramebufferObject, avec support multithread en arrière-plan). Le moteur de particules 2D Qt Quick.Particles 2.0 et la collection d’effets de shaders qui étaient avant des projets séparés dans Qt Labs sont maintenant inclus dans Qt.

Le module Qt 3D

Le module Qt 3D est également un ancien projet provenant de Qt Labs et est inclus dans Qt 5. Il a permis dans Qt 4 l’ajout de nombreuses fonctionnalités de calculs 3D comme les classes QMatrix4×4, QGLShaderProgram et QVector3D. Il utilise en interne le module Qt QML et le support OpenGL de Qt Gui. Ce module contient deux bibliothèques : Qt 3D (pour utiliser directement la 3D en C++) et Qt 3D Quick (pour l’utilisation dans Qt Quick).

Plusieurs fonctionnalités sont ajoutées :

• gestion de scènes 3D, avec rendu en OpenGL ;
• lecture de fichiers 3D (par exemple .obj et .3ds) ;
• gestion des lumières, des meshs, des textures, des matériaux, des animations, des caméras, des vues ;
• ajout de shader directement ou par fichier dans les propriétés QML ;

Le module Qt Location

Ce module est un ajout dans Qt 5, mais il existait déjà depuis des années comme sous-ensemble de Qt Mobility. Il fournit les services nécessaires pour la localisation : GPS, cartographie, etc.
Il inclut une fonctionnalité permettant d’afficher des cartes avec MapQuickItem. L’affichage se base sur une approche modèle/vue et bénéficie de l’accélération OpenGL dans scenegraph. Les gestuelles pour les zooms et les panoramas dynamiques, le routage et le géocodage, l’ajout de repères sur les cartes sont pris en charge.

Le module Qt Network

Ce module fournit une interface portable pour utiliser les réseaux. Parmi les évolutions :

• amélioration du support IPv6 et des réseaux utilisant les types d’adresse IP, de manière transparente par défaut. En réception, QTcpServer et QUdpSocket lancés avec QHostAddress::Any permet de recevoir dans les deux modes ; avec QHostAddress::AnyIPv4 et QHostAddress::AnyIPv6 permet de travailler sur un mode uniquement. En émission, QNetworkAccessManager tente d’utiliser les deux modes et garde le premier qui réussit ;
• QTcpSocket peut maintenant être attaché à un socket existant avant de lancer une connexion, pour limiter les connexions dans un environnement multihôte ;
• QDnsLookup permet de rechercher des enregistrements DNS. Il ne remplace pas QHostInfo, qui permet de résoudre les noms en adresse IP, mais permet principalement d’utiliser les autres types d’enregistrements DNS : SRV, TXT et MX ;
• les classes QFtp et QHttp ne sont pas conservées dans ce module, mais restent disponibles dans un module indépendant pour la compatibilité. Elles sont remplacées par QNetworkAccessManager.
• extensions et vérifications des certificats SSL : prise en charge des extensions des certificats. La vérification des certificats ne se fait plus uniquement lors de la connexion à un serveur ;
• support des clés privées masquées : permet de lire une clé privée à partir d’un périphérique, par exemple un dongle PKCS#11.

Les autres modules

• Qt Multimedia : fournit les fonctionnalités de base pour lire l’audio, la vidéo, la radio et gérer les caméras ;
• Qt SQL : fournit une prise en charge portable des bases de données SQL ;
• Qt Test : fournit les outils nécessaires pour implémenter des tests unitaires ;
• Qt WebKit : basé sur WebKit 2, mais sans changement de l’API C++. Ce module continue l’amélioration de prise en charge HTML 5 et des performances.

Les modules Add-ons

Le module Qt Widget

Ce module fournit l’ensemble des classes QWidget et dérivées pour la compatibilité avec Qt 4. Il utilise la nouvelle architecture Qt Platform Abstraction (QPA).

Le module Qt Quick 1

Ce module permet d’utiliser la version de Qt Quick disponible dans Qt 4, pour compatibilité. Pour utiliser ce module, il suffit d’ajouter dans le .pro :

Et d’inclure les fichiers d’en-têtes :

Les autres modules

• Qt Script : permet de rendre les applications scriptables, compatibilité avec Qt 4. Il utilise les classes QJSxxx du module Qt Js ;
• Qt Bluetooth : prise en charge du Bluetooth ;
• Qt D-Bus : interprocessus communication avec D-Bus ;
• Qt Graphical Effects : collection d’effets graphiques ;
• Qt Image Formats : prise en charge de formats d’images supplémentaires (TIFF, MNG, TGA, WBMP) ;
• Qt OpenGL : module 3D OpenGL compatible avec Qt 4 ;
• Qt Print Support : support pour l’impression ;
• Qt Publish and Subscribe ;
• Qt Script Tools : outils supplémentaires pour scripter ;
• Qt Sensor : gestion des capteurs (accéléromètre, détecteur de lumière ambiante, compas, etc.) ;
• Qt Service Framework : permet de fournir des services en ligne ;
• Qt SVG : prise en charge du format d’image SVG (image vectorielle) ;
• Qt System Info : informations sur le système (profile utilisateur, batterie, stockage, etc.) ;
• Qt Tools : outils divers (Qt Designer, Qt Help, etc.) ;
• Qt Pim : contacts, organiseur, vCard, etc. ;
• Qt WebKit Widgets : version de wekbit 1, pour compatibilité avec Qt 4 ;
• Qt XML : fichier XML avec SAX et DOM. Ce module est déprécié, il faut maintenant utiliser QXmlStreamReader/Writer ;
• Qt XML Patterns : support pour XPath, XQuery, XSLT et XML Schema validation.

Les modules accessoires

Le support de ces modules n’est pas encore déterminé.

• Active Qt : support des ActiveX et Com (Windows) ;
• Qt Feedback ;
• Qt JSON DB ;
• Phonon : support du framework phonon pour la vidéo et audio ;
• Qt QA : auto test, pour gestion automatique des tests ;
• Qt QLALR : interpréteur LALR.

Commentaires et remerciements

Vous pouvez commenter cet article sur le forum.
Merci à ClaudeLELOUP pour sa relecture orthographique.