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.

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

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.

Vous pouvez commenter cet article sur le forum

Les nouvelles extensions

L’extension ARB_debug_output (GL 4.1)

Dans la version OpenGL 4.1, a été ajouté l’extension ARB_debug_output, qui est une promotion de l’extension GL_AMD_debug_output proposée par AMD. Cette extension ajoute la possibilité de créer des contextes avec un mode de débogage. En l’activant, un système d’événements est activé et permet d’obtenir des informations variées, par exemple sur les problèmes rencontrés lors de la compilation des shaders GLSL, des appels de fonction non valides ou des problèmes potentiels de performance. Les messages générés par ce système peuvent être stockés dans une pile (« message log ») ou être récupérés par une fonction callback définie par l’utilisateur.

L’extension KHR_debug (GL 4.3)

Dans le but d’uniformiser les différentes versions d’OpenGL (en particulier avec OpenGL ES), l’évolution d’OpenGL tend à reprendre des fonctions provenant d’OpenGL ES. C’est le cas de l’extension KHR_debug dans OpenGL 4.3 qui est une promotion de l’extension ARB_debug_output d’OpenGL 4.1 et des extensions EXT_debug_marker et EXT_debug_label d’OpenGL ES. Cette extension ajoute ainsi des fonctions pour annoter les événements ou des groupes de commandes OpenGL.

Création d’un contexte de débogage (GL 4.1)

La première chose à faire pour utiliser un contexte de débogage est de vérifier que l’extension ARB_debug_output est bien prise en charge. Un exemple de code pour vérifier une extension est donné dans le tutoriel Les extensions OpenGL.

Pour créer un contexte de débogage, il faut simplement créer un contexte en appelant la fonction CreateContextAttribs avec le paramètre CONTEXT_DEBUG_BIT. En fonction du système d’exploitation, on aura donc un code équivalent à celui-ci :

Les fonctionnalités de débogage sont activées en utilisant la constante GL_DEBUG_OUTPUT. Celle-ci peut être activée ou désactivée avec glEnable et glDisable. Par défaut, cette constante est activée dans un contexte de débogage et désactivée dans le cas contraire.

Plusieurs niveaux de débogage sont possibles en fonction de la création ou non d’un contexte de débogage et de si l’on active GL_DEBUG_OUTPUT :

• si on ne crée pas un contexte de débogage et que l’on active GL_DEBUG_OUTPUT, les messages envoyés et le contenu sont laissés à l’appréciation des implémentations d’OpenGL, mais l’appel des fonctions de débogage ne produit pas d’erreur ;
• si on crée un contexte de débogage et que l’on n’active pas GL_DEBUG_OUTPUT, aucun message de débogage n’est lancé ;
• si on crée un contexte de débogage et que l’on active GL_DEBUG_OUTPUT, toutes les fonctionnalités de débogage sont activées.

Créer des contextes de débogage à partir d’une bibliothèque (GL 4.1)

Il existe plusieurs bibliothèques graphiques qui permettent de travailler sur des contextes OpenGL (SFML, SDL, Qt, etc.). Voyons comment créer un contexte de débogage dans ces cas d’utilisation.

Avec FreeGlut

FreeGlut fournit directement une constante pour créer un contexte en mode débogage : GLUT_DEBUG.

Avec Qt

La bibliothèque Qt fournit des outils pour créer et manipuler directement des fenêtres contenant un contexte OpenGL avec le module QtOpenGL. Pour créer un contexte spécifique d’une version OpenGL, il suffit simplement d’utiliser la fonction setVersion de la classe QGLFormat :

Pour plus de détails, voir l’article How to use OpenGL Core Profile with Qt sur le wiki de Qt.

Avec SFML 2.0

La bibliothèque SFML permet de demander lors de la création d’une fenêtre la version du contexte OpenGL à utiliser avec la classe sf::ContextSettings. S’il n’est pas possible de créer un contexte avec les paramètres demandés, SFML va créer un contexte le plus proche possible. Il est donc important de vérifier la version de contexte réellement créée.

Pour plus de détails, voir l’article Using OpenGL in a SFML window sur le site de SFML.

Avec SDL 1.3

La bibliothèque SDL fournit les constantes SDL_GL_CONTEXT_MAJOR_VERSION pour définir la version du contexte que l’on souhaite utiliser.

Pour plus de détails, voir l’article Creating a Cross Platform OpenGL 3.2 Context in SDL sur le site de SFML.

Les modes de synchronisation (GL 4.1)

Par défaut, les appels de fonction OpenGL sont asynchrones, ce qui veut dire que les fonctions peuvent simplement envoyer les commandes aux contextes OpenGL puis passent à l’instruction suivante dans le code. Par exemple, le code suivant peut poser des problèmes puisque rien ne garantit que l’on mesure réellement le temps d’exécution de la commande :

Lorsque l’on débogue une application utilisant OpenGL, il peut alors y avoir un décalage entre l’appel d’une fonction et une erreur générée. Pour faciliter le débogage, il est possible de changer le mode de synchronisation pour forcer OpenGL à attendre la fin de la commande avant de passer à l’instruction suivante dans le code. Cette fonctionnalité garantit la synchronisation dans un contexte, mais pas la synchronisation entre plusieurs contextes, qui reste sous la responsabilité de l’application.

Il est possible de tester le mode avec glIsEnabled et de le désactiver avec glDisable. Activer cette fonctionnalité peut être très coûteux en termes de performance et doit être utilisée uniquement pour le débogage.

La pile des évènements (GL 4.1)

La pile des évènements, appelée « message log » contient les messages lancés dans un contexte de débogage. Cette pile est de taille limitée, ce qui signifie que si elle est pleine, les événements les plus anciens seront perdus. Il faut donc la vider régulièrement en lisant les messages. Lorsque l’on utilise plusieurs contextes, chaque contexte possède sa propre pile des événements.

La fonction glGetIntegerv permet d’obtenir des informations sur les capacités et le contenu de la pile.

Les messages contenus dans la pile (GL 4.1)

Les messages dans la pile contiennent plusieurs informations comme l’origine du message, son type et son importance.

Origine du message :

• GL_DEBUG_SOURCE_API : le message est lancé lors d’un appel d’une fonction OpenGL ;
• GL_DEBUG_SOURCE_WINDOW_SYSTEM : le message est lancé par le gestionnaire de fenêtre ;
• GL_DEBUG_SOURCE_SHADER_COMPILER : le message est lancé par le compilateur de shader ;
• GL_DEBUG_SOURCE_THIRD_PARTY : le message est lancé par une bibliothèque externe ;
• GL_DEBUG_SOURCE_APPLICATION : le message est lancé par l’application (voir la partie « Envoyer un message personnalisé ») ;
• GL_DEBUG_SOURCE_OTHER : le message ne provient pas d’une des sources précédentes.

Type de message (l’utilisation des constantes spécifiques d’OpenGL 4.3 sera décrite dans la partie « L’extension KHR_debug » de ce billet) :

• GL_DEBUG_TYPE_ERROR : message d’erreur récupérable avec glEvent ;
• GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR : utilisation fonction dépréciée ;
• GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR : appel qui provoque un comportement indéfini ;
• GL_DEBUG_TYPE_PORTABILITY : problèmes de portabilité ;
• GL_DEBUG_TYPE_PERFORMANCE : notifications de performance ;
• GL_DEBUG_TYPE_OTHER : ne correspond pas aux types précédents ;
• GL_DEBUG_TYPE_MARKER : annotation (GL 4.3) ;
• GL_DEBUG_TYPE_PUSH_GROUP : entrée dans un groupe (GL 4.3) ;
• GL_DEBUG_TYPE_POP_GROUP : sortie d’un groupe (GL 4.3).

Importance du message :

• GL_DEBUG_SEVERITY_NOTIFICATION : les messages qui ne concernent pas les performances et les erreurs ;
• GL_DEBUG_SEVERITY_LOW : les alertes de performance concernant les changements redondants de contextes, les comportements indéfinis triviaux ;
• GL_DEBUG_SEVERITY_MEDIUM : les alertes de performance sévères, les alertes de compilation ou de linkage GLSL, utilisation d’un comportement déprécié ;
• GL_DEBUG_SEVERITY_HIGH : les erreurs OpenGL, les comportements indéfinis dangereux, les erreurs de compilation ou de link GLSL.

Les messages sont identifiés de façon unique grâce à la combinaison de leur type, leur source et un numéro d’identification.

Le dernier élément composant un message est une chaîne de caractères terminée par le caractère NULL (chaîne de caractères, style C) et donnant des informations plus détaillées sur le message.

Lire les messages dans la pile (GL 4.1)

La fonction glGetDebugMessageLog permet de lire un ou plusieurs messages contenus dans la pile.

Pour récupérer un message :

Pour récupérer les dix premiers messages :

Pour effacer tous les messages dans la pile :

Une erreur GL_INVALID_VALUE est lancée si le paramètre bufSize est négatif.

Envoyer un message personnalisé (GL 4.1)

Il est possible d’envoyer un message personnalisé avec la fonction glDebugMessageInsert. Cela permet d’écrire des bibliothèques graphiques ou de transmettre des erreurs entre différentes parties d’une application.

Les paramètres sont équivalents aux autres fonctions. Si length est négatif, alors message est une chaîne de caractères terminée par NULL.

Par exemple :

La fonction glDebugMessageInsert peut générer les erreurs suivantes :

• INVALID_ENUM : type n’est pas une valeur valide ou source ne vaut pas DEBUG_SOURCE_APPLICATION ou DEBUG_-
  SOURCE_THIRD_PARTY ;
• INVALID_VALUE : severity n’est pas une valeur valide ;
• INVALID_VALUE : le nombre de caractères de message est supérieur à MAX_DEBUG_MESSAGE_LENGTH.

Les filtres de messages (GL 4.1)

Dans de nombreux cas, il est souhaitable de pouvoir limiter les messages, pour éviter de perdre des messages s’ils sont trop nombreux et éviter de devoir gérer un trop grand nombre de messages. Il est alors possible d’ajouter un ou plusieurs filtres, pour supprimer certains types de messages ou au contraire n’en garder que certains. Les filtres appliqués ne seront actifs que sur les nouveaux messages et non sur ceux qui sont déjà sur la pile.

La fonction glDebugMessageControl permet d’ajouter un filtre :

Les paramètres source, type et severity prennent l’une des valeurs décrites au-dessus (GL_DEBUG_SOURCE_API, GL_DEBUG_SOURCE_WINDOW_SYSTEM, GL_DEBUG_SOURCE_SHADER_COMPILER, GL_DEBUG_SOURCE_THIRD_PARTY, GL_DEBUG_SOURCE_APPLICATION ou GL_DEBUG_SOURCE_OTHER pour source, GL_DEBUG_TYPE_ERROR, GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR, GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR, GL_DEBUG_TYPE_PORTABILITY, GL_DEBUG_TYPE_PERFORMANCE ou GL_DEBUG_TYPE_OTHER pour type et GL_DEBUG_SEVERITY_LOW, GL_DEBUG_SEVERITY_MEDIUM ou GL_DEBUG_SEVERITY_HIGH pour severity) ou GL_DONT_CARE pour ne pas prendre en compte le paramètre.

Le paramètre ids permet de donner un tableau d’identifiants de taille count. Si le paramètre count est supérieur à 0, alors le filtre s’applique aux messages dont les identifiants correspondent aux valeurs données dans le tableau ids. Dans ce cas, les paramètres source et type ne doivent pas être GL_DONT_CARE et severity doit être GL_DONT_CARE.

Le paramètre enabled permet de préciser si le filtre supprime les messages correspondant aux critères (GL_FALSE) ou les garde (GL_TRUE).

Par exemple, pour garder tous les messages :

Par exemple, pour ne garder que les messages importants :

Pour désactiver les messages correspondant à l’appel de fonctions dépréciées :

Pour ne garder que les messages correspondant à une liste d’identifiants donnés :

La fonction GLDebugMessageControl peut générer les erreurs suivantes :

• INVALID_ENUM : utilisation d’une valeur incorrecte pour source, type ou severity ;
• INVALID_VALUE : count est négatif ;
• INVALID_OPERATION : count est positif, mais source ou type valent DONT_CARE ou severity ne vaut pas DONT_CARE.

Pour éviter d’avoir à écrire deux codes, pour les versions debug et release, il est possible de créer une macro définissant ou non une fonction appelant les filtres :

Les fonctions callback (GL 4.1)

Une autre possibilité pour récupérer les messages est de créer une fonction callback qui sera appelée dès qu’un message est lancé. Les messages ne sont alors plus mis dans la pile et ne peuvent être lus avec glGetDebugMessageLog. Par contre, les filtres ajoutés avec GLDebugMessageControl continuent de fonctionner.

Une fonction callback doit avoir la signature suivante :

Les paramètres source, type, id, severity et message correspondent aux paramètres des messages comme décrit au-dessus. Le paramètre length est la taille de la chaîne de caractères message. La mémoire allouée pour le paramètre message est gérée directement par OpenGL. Sa portée correspond à la fonction callback, donc il est nécessaire de copier le message si on souhaite l’utiliser en dehors de la fonction. Le paramètre userParam est un pointeur vers des données pouvant être utilisées dans le corps de la fonction et passées lorsque l’on attache la fonction callback à un contexte.

Elle ne doit pas appeler de fonction OpenGL ou du système de fenêtrage. Cette fonction est appelée par un thread différent du thread appelant la fonction GL, il faut donc faire particulièrement attention au respect du thread-safe.
Lorsque l’on travaille avec plusieurs contextes OpenGL, il faut fournir une fonction callback pour chaque contexte pour lesquels on souhaite capturer les messages. Dans une application multithread, il est possible d’avoir une fonction callback sur un contexte appelé par plusieurs threads différents, mais l’application est responsable du respect du thread-safe.

Par exemple, la fonction suivante permet d’afficher dans la console les informations des messages reçus.

La fonction glDebugMessageCallback permet d’attacher une fonction callback à un contexte. Elle prend en paramètre la fonction callback et un pointeur vers des données utilisateurs. Sa signature est la suivante :

Le code d’exemple suivant présente comment attacher une fonction callback et modifier les données utilisateurs entre deux messages.

Pour supprimer une fonction callback, il suffit d’appeler glDebugMessageCallback avec des valeurs nulles ;

La fonction glGetPointerv permet de récupérer la fonction callback en utilisant le paramètre GL_DEBUG_CALLBACK_FUNCTION et les données userParam avec GL_DEBUG_CALLBACK_USER_PARAM :

Les annotations de débogage (GL 4.3)

Un des problèmes que l’on peut rencontrer lorsque l’on débogue une application est de savoir quels objets provoquent une erreur. Il est nécessaire alors de garder une table contenant les identifiants des objets. Dans OpenGL 4.3 a été ajouté les annotations de débogage (debug label), qui permettent d’attacher une chaîne de caractères à n’importe quel objet OpenGL grâce à la fonction glObjectLabel :

Le paramètre name correspond au numéro retourné par les fonctions create. Le paramètre identifier indique le type d’objet correspondant à name. Il peut prendre les valeurs suivantes :

• BUFFER
• FRAMEBUFFER
• PROGRAM_PIPELINE
• PROGRAM
• QUERY
• RENDERBUFFER
• SAMPLER
• SHADER
• TEXTURE
• TRANSFORM_FEEDBACK
• VERTEX_ARRAY

La fonction glObjectLabel peut générer les erreurs suivantes :

• INVALID_ENUM : si identifier n’est pas une valeur valide ;
• INVALID_VALUE : si name ne correspond pas à un objet valide de type identifier ;
• INVALID_VALUE : si la taille de la chaîne de caractères label est plus grande que MAX_LABEL_LENGTH.

La fonction glGetObjectLabel permet de récupérer l’annotation associée avec un objet identifié par identifier et name :

Cette fonction peut retourner les erreurs suivantes :

• INVALID_ENUM : si identifier ne correspond pas à un type d’objet valide ou si name ne correspond pas à un objet valide de type donné ;
• INVALID_VALUE : si bufSize est négatif.

En plus de la fonction glObjectLabel, la fonction glObjectPtrLabel permet d’annoter un objet de synchronisation (un objet de synchronisation permet de tester si des commandes OpenGL sont en cours ou terminées ; voir le chapitre 4 – Event model des spécifications d’OpenGL 4.3 pour plus de détails).

La fonction glObjectPtrLabel peut générer les erreurs suivantes :

• INVALID_VALUE : si ptr ne correspond pas à un objet de synchronisation valide ;
• INVALID_VALUE : si la taille de la chaîne de caractères label est plus grande que MAX_LABEL_LENGTH.

La fonction glGetObjectPtrLabel permet de récupérer le label d’un objet de synchronisation :

Les groupes de débogage (GL 4.3)

Les groupes permettent d’annoter un ensemble de fonctions OpenGL. Un message GL_DEBUG_TYPE_PUSH_GROUP est envoyé lorsque l’on entre dans le groupe puis GL_DEBUG_TYPE_POP_GROUP lorsque l’on sort. Il est également possible d’utiliser plusieurs groupes, qui seront alors hiérarchisés dans une pile de groupes. Les filtres appliqués sont actifs sur le groupe courant et les groupes qui seront inclus dans ce groupe. Au démarrage, la pile contient un groupe par défaut. Ce système permet ainsi de retrouver plus facilement l’origine des messages.

Les fonctions glPushDebugGroup et glPopDebugGroup permettent de débuter et finir un groupe.

Le message généré contient la chaîne de caractères message, l’identifiant id, le type sera DEBUG_TYPE_PUSH_GROUP ou DEBUG_TYPE_POP_GROUP, la source devra être GL_DEBUG_SOURCE_APPLICATION ou GL_DEBUG_SOURCE_THIRD_PARTY et severity sera GL_DEBUG_SEVERITY_NOTIFICATION.

La fonction glPushDebugGroup peut générer les erreurs suivantes :

• INVALID_ENUM : si la source ne correspond pas à DEBUG_SOURCE_APPLICATION ou DEBUG_SOURCE_THIRD_PARTY ;
• INVALID_VALUE : si la taille de message est supérieure à MAX_DEBUG_MESSAGE_LENGTH ;
• STACK_OVERFLOW : si le nombre de groupes dépasse MAX_DEBUG_GROUP_STACK_DEPTH – 1.

La fonction glPopDebugGroup peut générer une erreur STACK_UNDERFLOW si la pile de groupes ne contient que le groupe par défaut.

Notes sur les implémentations

Les situations pouvant générer des messages et le contenu de ces messages sont laissés à l’appréciation des implémentations. On observe donc des différences de comportement entre les différentes implémentations.
Pour le moment, la taille de la pile semble être de 128 messages et la taille des messages au maximum de 1024 octets chez AMD et NVIDIA.

Exemples de situations et de message générés

Lorsque l’on attache un tampon mémoire sur un objet ne correspondant pas à un tampon, NVIDIA ne donne aucun message alors que AMD retourne un message signalant une fonction dépréciée :

glBindBuffer in a Core context performing invalid operation
with parameter « name » set to ‘0x5′ which was removed
from Core OpenGL (GL_INVALID_OPERATION)

Lorsque l’on appelle une fonction dépréciée ou avec une combinaison dépréciée de paramètres, par exemple glPolygonMode(GL_FRONT, GL_LINE), NVIDIA et AMD retournent une erreur GL_INVALID_ENUM :

// NVIDIA
GL_INVALID_ENUM error generated. Polygonmodes for « face » are
disabled in the current profile.
// AMD
Using glPolygonMode in a Core context with parameter
« face » and enum ‘0x404′ which was removed from
Core OpenGL (GL_INVALID_ENUM)

Les messages peuvent également servir lorsqu’il n’y a pas d’erreur, par exemple pour faire le suivi des appels de fonction. Par exemple, lorsque l’on attache un tampon mémoire et que les données sont correctement envoyées, NVIDIA lance le message suivant en GL_DEBUG_SEVERITY_LOW alors que AMD ne lance rien.

Buffer detailed info: Buffer object 3 (bound to
GL_ELEMENT_ARRAY_BUFFER_ARB, usage hint
is GL_ENUM_88e4) will use VIDEO memory as
the source for buffer object operations.

Lorsqu’on appelle la fonction glDrawElement pour lancer un rendu alors que la mémoire graphique est pleine, NVIDIA va générer le message suivant :

Unknown internal debug message . The NVIDIA
OpenGL driver has encountered an out of memory
error. This application might behave inconsistently and fail.

Pour terminer, une situation posant des problèmes de performance. Lorsque l’on utilise un nombre important de Vertex Array Object de petites tailles, NVIDIA lancera un message signalant une perte de performance alors que AMD ne donne aucun message.

Sources et remerciements

Certains exemples (en particulier les messages d’erreurs générés dans certaines situations) proviennent du livre OpenGL Insight de Patrick Cozzi et Christophe Riccio, dont certains chapitres sont accessibles gratuitement sur le site du livre. Merci également à Christophe Riccio pour ses revues des spécifications d’OpenGL qu’il publie sur g-truc. Vous pouvez également consulter les spécifications d’OpenGL 4.3, en particulier le chapitre consacré au débogage : « Chapter 20 – Debug Output ».
Merci à f-leb pour sa relecture orthographique.

Imaginons que l’on souhaite créer une classe représentant un point en 3D. On écrit alors le code suivant :

On utilise ensuite cette classe à plusieurs endroits dans notre code, par exemple dans une fonction glVertex (remarque : pour ceux, qui comme LittleWhite bloquent sur l’utilisation de glVertex, je précise que ce n’est qu’un code d’exemple ; glVertex est une fonction dépréciée et ne doit plus être utilisée) :

Jusque là, tout va bien.

(Ou presque. Si on modifie les coordonnées d’un point, on obtient un nouveau point, bien distinct du premier. Les setters sont donc contraire au respect de la sémantique de valeur et doivent être évités.)

Là où les choses se gâtent

Nos besoins évoluent. Au lieu de simplement vouloir faire de la représentation 3D sur nos points, on doit également faire des calculs pour de la simulation physique. On a la chance d’avoir une carte graphique prenant en charge l’extension fp64 et on décide donc d’utiliser double au lieu de float :

Malheureusement, le code qui utilise cette classe Point3D doit également être modifié pour pouvoir compiler. En effet, glVertex3f prend comme paramètres des float, il faut maintenant utiliser glVertex3d qui prend comme paramètres des double :

La modification est relativement facile. Maintenant imaginons que cette classe Point3D est utilisée dans des centaines de ligne de code. Imaginons aussi que toutes vos classes présentent le même problème d’exposer des détails d’implémentation interne. À chaque fois que l’on doit modifier une classe, on se retrouve avec plein de bugs à la compilation et on doit perdre du temps à corriger toutes les lignes de code utilisant notre classe. C’est un problème que connaissent beaucoup de débutants (et d’autres développeurs plus anciens… mais aiment faire des erreurs de débutants). Quelle perte de temps ! On parle de couplage fort entre deux classes quand la modification de l’une de classe implique la modification de l’autre classe. Sinon, on parle de couplage faible.

En utilisant les templates, on améliore un peu la situation. On laisse la responsabilité de choisir le type utilisé en interne à l’utilisateur de notre classe. Il sait donc quelle fonction appeler selon le contexte :

Même si le code est meilleur que le précédent, il est encore améliorable. L’idéal serait de ne plus avoir à choisir manuellement la fonction à appeler et laisser le compilateur faire le travail pour nous.

Comment corriger ce problème ?

Le premier principe qui n’est pas respecté dans ce cas est le principe de ségrégation des interfaces. Ce principe dit « Une classe ou une fonction cliente ne doit pas dépendre d’interfaces dont elle n’a pas l’utilité » (source). Dit autrement, cela veut dire que si une classe A utilise une classe B et que cette classe B utilise une classe C, A n’a pas à connaître C. Dans notre exemple, il faudrait que le code qui utilise la classe Point3D n’a pas à connaître le type utilisé en interne (float ou double).

Mais le problème est plus profond (et critique) que cela. Le problème vient en fait d’une mauvaise compréhension de ce qu’est l’encapsulation. La règle est la suivante : « On encapsule un comportement, pas des propriétés » (source). Voyons ce que cela implique en pratique pour notre classe représentant un point en 3D. Si on pense en termes de propriétés, comme on l’a fait au début, un point dans un espace 3D est effectivement un objet représenté par ses trois composantes réelles x, y et z. Si on pense en terme de comportement, l’implémentation sera différente. Quels sont les comportements attendus pour notre point ? En suivant notre code d’exemple précédant, le seul comportement que l’on souhaite implémenter est de pouvoir l’afficher. On écrit donc simplement le code suivant :

La différence par rapport au code précédant est ridicule en terme de travail à fournir pour l’implémentation. On a simplement refactorisé l’appel à glVertex dans une fonction membre de Point3D. Par contre, en terme de sémantique, la différence est énorme : le code client n’a plus besoin de connaître les détails d’implémentation, notre code est plus facilement évolutif et donc efficace. Les modifications à apporter à notre code en cas de changement est localisé : on sait que si l’on modifie une variable membre d’une classe, on n’a que les fonctions membres de la classe à modifier et rien d’autre.

Si on est paresseux (et donc intelligent), on va utiliser la version template pour plus de souplesse, par exemple avec des spécialisations :

La version template demande un peu plus de ligne de code que la version non template et peu donc demander un peu plus de travail pour le développeur. Pour autant, elle est préférable puisqu’il ne sera plus nécessaire de modifier le code en fonction des besoins du code client (respect du principe ouvert-fermé). Si on a plusieurs fonctions qui dépendent du type utilisé en interne, on peut également utiliser une classe de traits et polices :

Avec ce code, la liste des fonctions à appeler en fonction du type utilisé en interne est localisé dans une même classe de traits. Et si on souhaite ajouter un nouveau type, il suffit d’ajouter une nouvelle spécialisation pour la classe de traits, sans rien modifier au code existant.

Pour terminer, un peu de lecture
Le respect de ces principes est une méthode pour éviter les couplages trop forts entre les classes. Il existe d’autres méthodes pour découpler des classes (ie diminuer la force du couplage). Tout le monde connait par exemple la séparation du code des classes dans un fichier d’en-tête (partie la moins susceptible d’être modifiée) et un fichier d’implémentation (partie plus facilement modifiable). On peut également citer l’idiome Pimpl (Pointer To Implementation) ou l’utilisation des signaux et slots, deux techniques très utilisée dans Qt.

En complément, Emmanuel Deloget a publié quelques articles intéressants sur les principes de programmation objet :

• valider et corriger une architecture objet première partie et seconde partie par Emmanuel Deloget ;
• le principe d’encapsulation, le principe de ségrégation des interfaces et le principe ouvert-fermé par Emmanuel Deloget ;
• la guerre des accesseurs par Emmanuel Deloget ;
• présentation des classes de Traits et de Politiques en C++ par Alp Mestan ;
• l’idome pImpl (WikiBooks) ;
• Boost.Signals (documentation de Boost) ;
• les signaux et slots dans Qt (documentation de Qt 4.8).

Commentaires
Vous pouvez réagir à ce billet sur le forum dans cette discussion. Merci.

Dans Qt4, les fonctionnalités d’OpenGL sont implémentées dans un module spécifique, QtOpenGL. Ce module était utilisé par différentes classes pour bénéficier de l’accélération matérielle. Il existe plusieurs méthodes pour activer l’accélération matérielle :

• pour activer par défaut l’utilisation de OpenGL, utiliser la ligne de commande « -graphicssystem opengl » ou la fonction QApplication::setGraphicsSystem(« opengl ») ;
• pour QGraphicsView (QtGraphics) ou QDeclarativeView (QtQuick), utiliser la fonction setViewport(new QGLWidget) ;
• on peut également utiliser QPainter directement sur un QGLWidget ;
• avec le QML Viewer, utilisez la commande « -opengl ».

L’organisation des modules
Dans Qt4, on a donc un problème dans l’organisation des modules. Beaucoup de classes de QtGui peuvent dépendre des classes appartenant à QtOpenGL alors que ce module dépend normalement de QtGui.
C’est pour cela que de nouvelles classes font leur apparition dans Qt5 et que les différents modules ont été réorganisés :

• les classes QOpenGL appartiennent au module QtGui et fournissent les fonctionnalités de base permettant l’accélération matérielle pour toute les classes de rendu de Qt ;
• la classe QWidget n’est plus le parent de toutes les classes de rendu. Cette classe et ses dérivées (QGraphicsView) sont transférées dans le module « widgets » ;
• QtQuick 2 utilise maintenant scenegraph à la place de QWidget et la classe QDeclarativeView devient QQuickView et OpenGL est utilisé par défaut ;
• QtOpenGL continue d’exister pour fournir la classe QGLWidget et ses dérivés. Le code OpenGL Qt4 est donc compatible avec Qt5 ;
• le module Qt3d fait son apparition pour fournir un moteur 3D plus avancé. Ce module est suffisamment important et fera donc l’objet d’un article spécifique.

Remarque : il faut faire attention de ne pas confondre le module QtOpenGL, contenant les classes commençant par QGL, et le module QtGui, contenant les classes commençant par QOpenGL (sans t).

Les classes de QtGui dans Qt5
Le module QtGui de Qt5 réutilise des classes existantes du module QtOpenGL de Qt4. Les noms sont explicites :

1. QOpenGLBuffer ;
2. QOpenGLContext ;
3. QOpenGLFramebufferObject ;
4. QOpenGLFramebufferObjectFormat ;
5. QOpenGLShader ;
6. QOpenGLShaderProgram.

Plusieurs nouvelles classes font leur apparition :

1. QOpenGLContextGroup : groupe de contextes OpenGL pouvant partager des ressources. Cette classe est gérée automatiquement par les objets QOpenGLContext ;
2. QOpenGLFunctions : fournit un accès indépendant de la plateforme aux fonctions d’OpenGL ;
3. QOpenGLPaintDevice : permet de dessiner dans un contexte OpenGL avec QPainter ;
4. QOpenGLStaticContext : manque de documentation ;
5. QOpenGLContextData : manque de documentation ;
6. QWindowsGLContext : manque de documentation.

Que faut-il modifier pour utiliser OpenGL dans Qt5
Tout d’abord, il faut Qt5. Le plus simple est d’utiliser les dépôts PPA sur Ubuntu : https://launchpad.net/~forumnokia/+archive/fn-ppa. Qt5 sera installé dans le répertoire /opt/qt5. Pour ajouter cette version de Qt dans QtCreator, il faut aller dans le menu « Outils » puis « Options… », allez dans « Compiler et exécuter… » puis l’onglet « Versions de Qt ». Cliquer sur « Ajouter » et aller chercher le fichier « /opt/qt5/bin/qmake ». Voilà, Qt5 est prêt à être utilisé.

Normalement, vous pouvez utiliser vos projets directement, mais il est préférable de prendre l’habitude d’ajouter le module « widgets » (remarque : l’ajout des modules core et gui n’est pas obligatoire puisqu’ils sont inclus par défaut) :

Amusez-vous bien !