# Programmation GTK/Gestion d'évènements

* Introduction
* Bien débuter
** « Bonjour tout le monde » en GTK
** Compilation de « Bonjour tout le monde »
** Théorie des signaux et des rappels
** « Bonjour tout le monde » pas à pas
** Types de données
** Compléments sur les gestionnaires de signaux
** Un « Bonjour tout le monde » amélioré
* Placement des widgets
** Théorie des boîtes de placement
** Détails sur les boîtes
** Programme de démonstration des placements
** Placement avec les tables
** Exemple de placement avec table
* Vue d'ensemble des widgets
** Conversions de types
** La hiérarchie des widgets
** Widgets sans fenêtre
* Widgets boutons
** Boutons normaux
** Boutons commutateurs
** Cases à cocher
** Boutons radio
* Widgets divers
** Labels
** Le widget bulle d'aide
** Barres de progression
** Boîtes de dialogue
** Pixmaps
* Widgets containers
** Bloc-notes
** Fenêtres avec barres de défilement
* Widgets listes
** Signaux
** Fonctions
** Exemple
** Widget item de liste
* Widgets de sélections de fichiers
* Widgets Menu
** Création manuelle de menus
** Exemple de menu manuel
** Utilisation de GtkMenuFactory
** Exemple d'usine à menu
* Widgets non documentes
** Entrées de texte
** Sélections de couleurs
** Contrôle d'intervalle
** Règles
** Boîtes de texte
** Prévisualisation
** Courbes
* Widget EventBox
* Configuration des attributs de widget
* Temporisations, fonctions d'E/S et d'attente
** Temporisations
** Surveillance des E/S
** Fonctions d'attente
* Gestion des sélections
** Introduction
** Récupération de la sélection
** Fournir la sélection
* glib
** Définitions
** Listes doublement chaînées
** Listes simplement chaînées
** Gestion de la mémoire
** Timers
** Gestion des chaînes
** Utilitaires et fonctions d'erreurs
* Fichiers rc de GTK
** Fonctions pour les fichiers rc
** Format des fichiers rc de GTK
** Exemple de fichier rc
* Écriture de vos propres widgets
** Vue d'ensemble
** Anatomie d'un widget
** Création d'un widget composé
** Création d'un widget à partir de zéro
** En savoir plus
* Scribble, un programme simple de dessin
** Présentation
** Gestion d'événement
** Le widget DrawingArea et le dessin
** Ajouter le support XInput
* Conseils pour l'écriture d'applications GTK
* Contributions
* Remerciements
* Copyright
* Introduction
* Bien débuter
** « Bonjour tout le monde » en GTK
** Compilation de « Bonjour tout le monde »
** Théorie des signaux et des rappels
** « Bonjour tout le monde » pas à pas
** Types de données
** Compléments sur les gestionnaires de signaux
** Un « Bonjour tout le monde » amélioré
* Placement des widgets
** Théorie des boîtes de placement
** Détails sur les boîtes
** Programme de démonstration des placements
** Placement avec les tables
** Exemple de placement avec table
* Vue d'ensemble des widgets
** Conversions de types
** La hiérarchie des widgets
** Widgets sans fenêtre
* Widgets boutons
** Boutons normaux
** Boutons commutateurs
** Cases à cocher
** Boutons radio
* Widgets divers
** Labels
** Le widget bulle d'aide
** Barres de progression
** Boîtes de dialogue
** Pixmaps
* Widgets containers
** Bloc-notes
** Fenêtres avec barres de défilement
* Widgets listes
** Signaux
** Fonctions
** Exemple
** Widget item de liste
* Widgets de sélections de fichiers
* Widgets Menu
** Création manuelle de menus
** Exemple de menu manuel
** Utilisation de GtkMenuFactory
** Exemple d'usine à menu
* Widgets non documentes
** Entrées de texte
** Sélections de couleurs
** Contrôle d'intervalle
** Règles
** Boîtes de texte
** Prévisualisation
** Courbes
* Widget EventBox
* Configuration des attributs de widget
* Temporisations, fonctions d'E/S et d'attente
** Temporisations
** Surveillance des E/S
** Fonctions d'attente
* Gestion des sélections
** Introduction
** Récupération de la sélection
** Fournir la sélection
* glib
** Définitions
** Listes doublement chaînées
** Listes simplement chaînées
** Gestion de la mémoire
** Timers
** Gestion des chaînes
** Utilitaires et fonctions d'erreurs
* Fichiers rc de GTK
** Fonctions pour les fichiers rc
** Format des fichiers rc de GTK
** Exemple de fichier rc
* Écriture de vos propres widgets
** Vue d'ensemble
** Anatomie d'un widget
** Création d'un widget composé
** Création d'un widget à partir de zéro
** En savoir plus
* Scribble, un programme simple de dessin
** Présentation
** Gestion d'événement
** Le widget DrawingArea et le dessin
** Ajouter le support XInput
* Conseils pour l'écriture d'applications GTK
* Contributions
* Remerciements
* Copyright
[ Modifier le sommaire ]

# Scribble, un programme simple de dessin
## Présentation

Dans cette section, nous construirons un programme simple de dessin. Ce faisant, nous examinerons comment gérer les événements souris, comment dessiner dans une fenêtre, et comment mieux dessiner en utilisant un pixmap en arrière plan. Après avoir créé ce programme, nous l'étendrons en lui ajoutant le support des périphériques Xinput, comme les tables de tracé. GTK dispose de routines de support qui facilitent beaucoup l'obtention des informations étendues (comme la pression et l'inclinaison du stylet) à partir de tels périphériques.

## Gestion d'événement

Les signaux GTK que nous avons déjà vus concernent les actions de haut niveau, comme la sélection d'un choix d'un menu. Cependant, il est quelques fois utile de connaître les cas de bas niveau, comme le déplacement de la souris, ou la pression d'une touche. Il existe aussi des signaux GTK correspondant à ces événements bas niveau. Les gestionnaires de ces signaux ont un paramètre supplémentaire qui est un pointeur vers une structure contenant des informations sur l'événement. Par exemple, les gestionnaires des événements de déplacement recoivent un paramètre vers une structure GdkEventMotion qui ressemble (en partie) à ceci :
type sera initialisé avec le type de l'événement, ici GDK_MOTION_NOTIFY, window est la fenêtre dans laquelle l'événement est survenu. x et y donnent les coordonnées de l'événement et state spécifie l'état du modificateur lorsque l'événement s'est produit (c'est-à-dire quelles sont les touches de modification et les boutons souris qui ont été pressés). Il s'agit d'un OU bit à bit de l'une des valeurs suivantes :
Comme pour les autres signaux, on appelle gtk_signal_connect pour déterminer ce qui se passe lorsqu'un événement survient. Mais nous devons aussi faire en sorte que GTK sache de quels événements nous voulons être avertis. Pour ce faire, on appelle la fonction :
Le deuxième champ spécifie les événements qui nous intéressent. Il s'agit d'un OU bit à bit de constantes qui indiquent différent types d'événements. Pour référence ultérieure, les types d'événements sont :
Il y a quelques points subtils qui doivent être observés lorsqu'on appelle gtk_widget_set_events. D'abord, elle doit être appelée avant que la fenêtre X d'un widget GTK soit créée. En pratique, cela signifie que l'on doit l'appeler immédiatement après avoir créé le widget. Ensuite, le widget doit avoir une fenêtre X associée. Pour des raisons d'efficacité, de nombreux types de widgets n'ont pas de fenêtre propre, mais se dessinent dans la fenêtre de leur parent. Ces widgets sont :
Pour capturer les événements pour ces widgets, on doit utiliser un widget EventBox. Voir la section sur Le widget EventBox pour plus de détails.
Pour notre programme de dessin, on veut savoir quand le bouton de la souris est pressé et quand la souris est déplacée, nous indiquons donc GDK_POINTER_MOTION_MASK et GDK_BUTTON_PRESS_MASK. On veut aussi savoir quand il est nécessaire de redessiner notre fenêtre, on indique donc GDK_EXPOSURE_MASK. Bien que nous voulions être avertis via un événement Configure lorsque la taille de notre fenêtre change, on n'a pas besoin de préciser le flag GDK_STRUCTURE_MASK correspondant car il est automatiquement spécifié pour chaque fenêtre.
Il arrive cependant qu'il puisse y avoir un problème en indiquant seulement GDK_POINTER_MOTION_MASK. Cela fera que le serveur ajoutera un nouvel événement de déplacement à la file des événements à chaque fois que l'utilisateur déplace la souris. Si cela nous prend 0,1 seconde pour gérer un événement de déplacement, si le serveur X n'ajoute un nouvel événement de déplacement dans la queue que toutes les 0,05 secondes, nous serons vite à la traîne de l'utilisateur. Si l'utilisateur dessine pendant 5 secondes, cela nous prendra 5 secondes de plus pour le traiter après qu'il ait relâché le bouton de la souris ! Ce que l'on voudrait, c'est ne récupérer qu'un événement de déplacement pour chaque événement que l'on traite. Pour cela, il faut préciser GDK_POINTER_MOTION_HINT_MASK.
Avec GDK_POINTER_MOTION_HINT_MASK, le serveur nous envoie un événement de déplacement la première fois que la pointeur se déplace après être entré dans la fenêtre, ou après un événement d'appui ou de relâchement d'un bouton. Les événements de déplacement suivants seront supprimés jusqu'à ce que l'on demande explicitement la position du pointeur en utilisant la fonction :
(Il existe une autre fonction, gtk_widget_get_pointer qui possède une interface simple, mais n'est pas très utile car elle ne fait que récupérer la position de la souris et ne se préoccupe pas de savoir si les boutons sont pressés).
Le code pour configurer les événements pour notre fenêtre ressemble alors à :
Nous garderons les gestionnaires de "expose_event" et "configure_event" pour plus tard. Les gestionnaires de "motion_notify_event" et "button_press_event" sont très simples :

## Le widget DrawingArea et le dessin

Revenons au processus de dessin sur l'écran. Le widget que l'on utilise pour ceci est le widget DrawingArea. Un tel widget est essentiellement une fenêtre X et rien de plus. Il s'agit d'une toile vide sur laquelle nous pouvons dessiner ce que nous voulons.
Une zone de dessin est créée avec l'appel :
Une taille par défaut peut être donnée au widget par l'appel :
Cette taille par défaut peu être surchargée en appelant gtk_widget_set_usize et celle-ci, à son tour, peut être surchargée si l'utilisateur modifie manuellement la taille de la fenêtre contenant la zone de dessin.
Il faut noter que lorsque l'on crée un widget DrawingArea, nous sommes complètement responsable du dessin du contenu. Si notre fenêtre est cachée puis redécouverte, nous recevrons un événement d'exposition et devrons redessiner ce qui a été caché auparavant.
Devoir se rappeler tout ce qui a été dessiné à l'écran pour pouvoir correctement le redessiner peut s'avérer, c'est le moins que l'on puisse dire, pénible. De plus, cela peut être visible si des portions de la fenêtre sont effacées puis redessinées étape par étape. La solution à ce problème est d'utiliser un pixmap d'arrière-plan qui n'est pas sur l'écran. Au lieu de dessiner directement à l'écran, on dessine sur une image stockée dans la mémoire du serveur et qui n'est pas affichée, puis, lorsque l'image change ou lorsque de nouvelles portions de l'image sont affichées, on copie les parties adéquates sur l'écran.
Pour créer un pixmap mémoire, on appelle la fonction :
Le paramètre windows indique une fenêtre GTK de laquelle ce pixmap tire certaines de ses propriétés. width et height précisent la taille du pixmap. depth précise la profondeur de couleur, c'est-à-dire le nombre de bits par pixel, de la nouvelle fenêtre. Si cette profondeur vaut -1, elle correspondra à celle de window.
Nous créons le pixmap dans notre gestionnaire "configure_event". Cet événement est généré à chaque fois que la fenêtre change de taille, y compris lorsqu'elle initialement créée.
L'appel à gdk_draw_rectangle remet le pixmap à blanc. Nous en dirons un peu plus dans un moment.
Notre gestionnaire d'événement d'exposition copie alors simplement la partie concernées du pixmap sur l'écran (on détermine la zone qu'il faut redessiner en utilisant le champ event->area de l'événement d'exposition)&nbsp:
Nous avons vu comment garder l'écran à jour avec notre pixmap, mais comment dessine-t-on réellement ce que l'on veut dans le pixmap ? Il existe un grand nombre d'appels dans la bibliothèque GDK de GTK pour dessiner sur des dessinables. Un dessinable est simplement quelque chose sur lequel on peut dessiner. Cela peut être une fenêtre, un pixmap, ou un bitmap (une image en noir et blanc). Nous avons déjà vu plus haut deux de ces appels, gdk_draw_rectangle et gdk_draw_pixmap. La liste complète est :
Consultez la documentation de référence ou le fichier en-tête <gdkgdk.h>/ pour plus de détails sur ces fonctions. Celles-ci partagent toutes les mêmes deux paramètres. Le premier est le dessinable sur lequel dessiner, le second est un contexte graphique (GC).
Un contexte graphique encapsule l'information sur des choses comme les couleurs de premier et d'arrière plan et la largeur de ligne. GDK possède un ensemble complet de fonctions pour créer et manipuler les contextes graphiques, mais, pour simplifier, nous n'utiliserons que les contextes graphiques prédéfinis. Chaque widget a un style associé (qui peut être modifié dans un fichier gtkrc, voir la section sur les fichiers rc de GTK). Celui-ci, entre autres choses, stocke plusieurs contextes graphiques. Quelques exemples d'accès à ces contextes sont :
Les champs fg_gc, bg_gc, dark_gc et light_gc sont indexés par un paramètre de type GtkStateType qui peut prendre les valeurs :
Par exemple, pour GTK_STATE_SELECTED, la couleur de premier plan par défaut est blanc et la couleur d'arrière plan par défaut est bleu foncé.
Notre fonction draw_brush, qui réalise le dessin à l'écran est alors :
Après avoir dessiné le rectangle représentant la brosse sur le pixmap, nous appelons la fonction :
qui indique à X que la zone donnée par le paramètre area a besoin d'être mise à jour. X génèrera éventuellement un événement d'exposition (en combinant peut-être les zones passés dans plusieurs appels à gtk_widget_draw) ce qui forcera notre gestionnaire d'événement d'exposition à copier les parties adéquates à l'écran.
Nous avons maintenant couvert entièrement le programme de dessin, sauf quelques détails banals comme la création de la fenêtre principale. Le code source complet est disponible à l'endroit où vous avez obtenu ce didacticiel.

## Ajouter le support XInput

Il est maintenant possible d'acheter des périphériques bon marché, comme les tablettes graphiques qui permettent d'exprimer beaucoup plus facilement son talent qu'avec une souris. La façon la plus simple pour utiliser de tels périphériques est simplement de le faire comme un remplacement de la souris, mais cela ne tire pas partie des nombreux avantages de ces périphériques, comme :
* Sensibilité à la pression ;
* rapport d'inclinaison ;
* positionnement au dessous du pixel ;
* entrées multiples (par exemple, un stylet avec pointe et gomme).
Pour des informations sur l'extension XInput, voir XInput-HOWTO.
Si l'on examine la définition complète de, par exemple, la structure GdkEventMotion, on voit qu'elle possède des champs pour supporter des informations étendues sur les périphériques.
pressure indique la pression comme un nombre réel compris entre 0 et 1. xtilt et ytilt peuvent prendre des valeurs entre -1 et 1, correspondant au degré d'inclinaison dans chaque direction, source et deviceid précisent de deux façons différentes le périphérique pour lequel l'événement est survenus. source donne une simple information sur le type du périphérique. Il peut prendre l'une des valeurs suivantes :
deviceid précise un ID numérique unique pour le périphérique. Il peut être utilisé pour trouver des informations supplémentaires sur le périphérique en utilisant l'appel gdk_input_list_devices (voir ci-dessous). La valeur spéciale GDK_CORE_POINTER sert à désigner le périphérique de pointage principal (habituellement la souris). Valider l'information supplémentaire sur un périphérique
Pour indiquer à GTK que l'on désire obtenir des informations supplémentaires sur le périphérique, on a simplement besoin d'ajouter une ligne à nos programmes.
gtk_widget_set_extension_events (drawing_area, GDK_EXTENSION_EVENTS_CURSOR);
En donnant la valeur GDK_EXTENSION_EVENTS_CURSOR, on indique que nous désirons les événements d'extension, mais seulement si l'on ne doit pas dessiner notre propre curseur. Voir la section Sophistications supplémentaires ci-dessous pour des plus de détails sur le dessin du curseur. Nous pourrions aussi donner les valeurs GDK_EXTENSION_EVENTS_ALL si nous voulons dessiner notre propre curseur, ou GDK_EXTENSION_EVENTS_NONE pour revenir à la situation par défaut.
Toutefois, nous ne sommes pas complètement à la fin de l'histoire. Par défaut, aucun périphérique d'extension n'est autorisé. Nous avons besoin d'un mécanisme pour que les utilisateurs puissent autoriser et configurer leur extensions. GTK dispose du widget InputDialog pour automatiser cette tâche. La procédure suivante gère un widget InputDialog. Elle crée le dialogue s'il n'est pas présent et le place au premier plan sinon.
(vous pouvez remarquer la façon dont nous gérons ce dialogue. En le connectant au signal "destroy", nous nous assurons que nous ne garderons pas un pointeur sur le dialogue après l'avoir détruit -- cela pourrait provoquer une erreur de segmentation).
InputDialog a deux boutons "Close" et "Save", qui n'ont pas d'actions qui leur sont assignées par défaut. Dans la fonction ci-dessus, nous associons à "Close" le masquage du dialogue et nous cachons le bouton "Save" car nous n'implantons pas la sauvegarde des options XInput dans ce programme. Utiliser l'information supplémentaire d'un périphérique
Lorsque l'on a validé le périphérique, on peut simplement utiliser l'information supplémentaire des champs des structures d'événement. En fait, il est toujours prident d'utiliser ces informations car ces champs auront des valeurs par défaut judicieuses même lorsque les événements supplémentaires ne sont pas autorisés.
La seule modification consiste à appeler gdk_input_window_get_pointer au lieu de gdk_window_get_pointer. Cela est nécessaire car gdk_window_get_pointer ne retourne pas l'information supplémentaire.
Lorsque l'on appelle cette fonction, on doit préciser l'ID du périphérique ainsi que la fenêtre. Habituellement, on aura obtenu cet ID par le champ deviceid d'une structure d'événement. Cette fonction retournera une valeur cohérente lorsque les événements ne sont pas autorisés (dans ce cas, event->deviceid aura la valeur GDK_CORE_POINTER).
La structure de base des gestionnaires d'événements de déplacement et de bouton pressé ne change donc pas trop -- il faut juste ajouter le code permettant de traiter l'information supplémentaire.
On doit aussi faire quelquechose de cette nouvelle information. Notre nouvelle fonction draw_brush dessine avec une couleur différente pour chaque event->source et change la taille du pinceau selon la pression.
En savoir plus sur un périphérique
Notre programme affichera le nom du périphérique qui a généré chaque appui de bouton. Pour trouver le nom d'un périphérique, nous appelons la fonction :
qui retourne une GList (un type de liste chaînée de la bibliothèque glib) de structures GdkDeviceInfo. La structure GdkDeviceInfo est définie de la façon suivante&nbsp:
La plupart de ces champs sont des informations de configuration que l'on peut ignorer sauf si l'on implante la sauvegarde de la configuration XInput. Celui qui nous intéresse est name qui est, tout simplement, le nom que X donne au périphérique. L'autre champ, qui n'est pas une information de configuration, est has_cursor. Si has_cursor est faux, on doit dessiner notre propre curseur, mais puisque nous avons précisé GDK_EXTENSION_EVENTS_CURSOR, nous n'avons pas à nous en préoccuper.
Notre fonction print_button_press ne fait parcourir la liste retournée jusqu'à trouver une correspondance, puis affiche le nom du périphérique.
Ceci termine les modifications de notre programme « XInputize ». Comme pour la première version, le code complet est disponible à l'endroit où vous avez obtenu ce didacticiel. Sophistications supplémentaires
Bien que notre programme supporte maintenant XInput, il y manque des caractéristiques que l'on souhaite trouver dans les applications complètes. D'abord, l'utilisateur ne veut probablement pas avoir à configurer ses périphériques à chaque fois qu'il lance le programme et nous devons donc lui permettre de sauvegarder la configuration du périphérique. Ceci est réalisé en parcourant ce que retourne gdk_input_list_devices et en écrivant la configuration dans un fichier.
Pour restaurer un état au prochain démarrage du programme, GDK dispose de fonctions pour changer la configuration des périphériques :
(La liste retournée par gdk_input_list_devices ne doit pas être modifiée directement). Un exemple est donné dans le programme de dessin gsumi (disponible à l'adresse http://www.msc.cornell.edu/~otaylor/gsumi/). De plus, ce serait pratique d'avoir une méthode standard pour faire cela pour toutes les applications. Ceci appartient probablement à un niveau légèrement supérieur à GTK, peut-être dans la bibliothèque GNOME.
Une autre grosse omission que nous avons mentionnée plus haut est l'absence de dessin du curseur. Les plates-formes autres qu'XFree86 n'autorisent pas encore l'utilisation simultanée d'un périphérique comme pointeur de base et comme pointeur d'une application. Lisez le XInput-HOWTO pour plus d'informations là-dessus. Ceci signifie que les applications qui veulent atteindre le plus de monde possible doivent dessiner leur propre curseur.
Une application qui dessine son propre curseur doit faire deux choses&nbsp: déterminer si le périphérique courant a besoin ou non d'un curseur dessiné et déterminer si le périphérique courant est à proximité (si celui-ci est une tablette de dessin, il est pratique de faire disparaître le curseur lorsque le stylet est en dehors de la tablette. Lorsque le périphérique voit le stylet, on dit qu'il est « à proximité »). La première vérification est faite en recherchant dans la liste des périphériques, comme nous l'avons fait pour obtenir le nom du périphérique. La deuxième est réalisée en choisissant des événements "proximity_out". Une exemple de dessin d'un curseur personnel est donné dans le programme testinput de la distribution GTK. Previous Next Table of Contents