You are on page 1of 24

Le systme de fentres X Window

Pierre-Alain Muller

Le systme de fentres X Window


Xlib, Xt Intrinsics et Motif
Introduction
The X Window System, ou alors X Window, ou X tout court, mais surtout pas X-Windows.
X est le standard industriel pour les stations de travail. X a t dvelopp au MIT avec laide
financire de DEC et IBM (projet Athena). Le nom X, de mmes que certaines notions de base de la
conception drivent des travaux effectus sur un systme de fentres antrieur (dnomm W) et
effectu Stanford.
X10 .... X11R4, X11R5 et maintenant X11R6.
En 1987, une douzaine de constructeurs de stations de travail on adopt X comme standard pour
leurs interfaces utilisateurs. Il existe aujourdhui des terminaux spcifiques pour X, appels
terminaux X.
X se distingue dautres systmes (comme le Macintosh dApple, ou Windows de Microsoft) par le
fait quil ne dfinit pas de style dinterface particulier. X est un ensemble de mcanismes
indpendants des constructeurs, des systmes dexploitation, des styles dinterfaces.
1. Les buts du systme X Window
X offre un environnement pour les stations de travail, transparent du point de vue du rseau et
totalement indpendant des constructeurs.
transparence rseau : une application qui sexcute sur un CPU donn peut sortir des donnes sur
nimporte quel cran, quil soit connect au mme CPU ou un autre CPU.
Architecture Client / Serveur :
Clients
SUN

IBM

TX

DEC

Serveurs

HP

WS

Le systme de fentres X Window

Pierre-Alain Muller

Grce la transparence rseau il est possible dexcuter les applications sur le CPU le plus
appropri (machine la moins charge, binaire pour ce CPU, base de donne centralise, protection
par machine, ...).
Il nest pas ncessaire de modifier les applications pour utiliser un cran connect un autre CPU.
Pour lutilisateur, tout se passe comme si le terminal X tait connect plusieurs ordinateurs
simultanment. De mme, une application X peut utiliser plusieurs crans en mme temps.

App 1

App 2

TX

App

TX 1

TX 2

TX 3

1.1. Indpendance et portabilit


Les applications X sont portables (en ce qui concerne linterface), car elles ne se proccupent pas
des particularits (matrielles, langages et systmes dexploitation). Les crans sont encapsuls par
X. Les diffrences dimplmentation (ou de capacits) sont dissimules par le protocole X. De ce
fait, une application qui utilise le protocole X, et seulement le protocole X, peut utiliser nimporte
quel terminal, de nimporte quel constructeur, sans recompilation (ni dition de liens). Bien
entendu, il faut quand mme compiler et linker la partie client X pour la combinaison particulire
(CPU/OS) qui excutera le programme. (Le protocole X ne rend pas les binaires compatibles entre
eux !). X assure galement la conversion entre les formats big-endian et little-endian .
1.2. Les dispositifs de sortie
X offre de nombreuses oprations pour manipuler (accder) les crans de type bit-mapped , X
nest pas prvu pour les terminaux alpha-numriques. X permet de montrer, de manipuler et de
capturer des images.
X organise les crans en hirarchie de fentres superposes. Chaque application utilise le
nombre de fentres qui lui convient, elle peut les retailler, les bouger et les empiler les unes sur les
autres.
X offre des mcanismes pour dessiner. Les oprations sont dites immdiates . Les stations de
travail ne stockent pas les requtes, elles les excutent immdiatement. Les oprations de dessins
sont orientes bitmap . Les applications adressent des pixels (adresses entires) au sein des
fentres. Les applications ne sont pas concernes par la position des fentres sur lcran.
X offre des mcanismes pour crire du texte de haute qualit. Par exemple de lmulation de
terminal mais aussi du traitement de texte volu.
2

Le systme de fentres X Window

Pierre-Alain Muller

X fonctionne avec une large gamme de terminaux graphiques. En couleur, en niveaux de gris et
monochrome.
1.3. Les dispositifs d'entre
X offre un ensemble de mcanismes pour la distribution des informations en provenance des
utilisateurs vers les applications.
Les utilisateurs gnrent des informations dentre par lintermdiaire des touches du clavier ou des
boutons de la souris. Ces informations sont distribues par le systme X sous la forme
dvnements.
De nombreux types dvnements permettent de dterminer les changements appliqus aux fentres
et la hirarchie des fentres.
X supporte un grand nombre de claviers et de jeu de caractres.
1.3.1. La souris (tablette, boule, scanner, ...)
La souris est le dispositif dentre le plus populaire, il est utilis la fois pour dsigner et pour
slectionner. Lutilisateur pointe une position sur lcran en dplaant une petite image dnomme
sprite (mouse cursor), X utilise le terme de pointer . Les applications clientes peuvent
changer la forme du sprite volont (exemple : pour indiquer une activit longue => la montre ou le
sablier). Un point particulier (le hotspot ) dfinit la position prcise du sprite sur lcran. Le
sprite est dans une fentre lorsque le hotspot est dans cette fentre.

1.3.2. Le clavier
A chaque touche du clavier correspond un code didentification. Le client peut traduire ce code en
caractre ASCII sil le dsire. Le code est compltement indpendant des claviers ce qui rend les
applications indpendantes des constructeurs.
3

Le systme de fentres X Window

Pierre-Alain Muller

1.4. Les fentres


La fentre est le concept de base. Chaque fentre reprsente une zone rectangulaire. Contrairement
dautres systmes (Mac, Windows, Next, ...) une fentre X ne comporte aucune dcoration (pas de
barre de titre, dascenseur, ...). Une fentre X se prsente comme un rectangle avec une couleur de
fond ou un motif de fond, entoure dune bordure.

Root Window

D
A

C
H
E
G

Le serveur X cre les fentres suite aux requtes des clients. Le serveur encapsule toutes les
informations utiles sur les fentres. Les applications clientes ne connaissent les fentres que par
lintermdiaire dun identificateur. Les clients peuvent demander au serveur de modifier ou
dplacer les fentres, sans pour autant tre le propritaire de la fentre. Une application A peut donc
modifier une fentre cre par une application B. Cette fonctionnalit est utilise par les
gestionnaires de fentres par exemple.
1.4.1. La hirarchie des fentres
X organise les fentres en hirarchie ( window tree ). La fentre racine est dnomme la root
window . Le serveur X cr une fentre racine pour chaque cran plac sous son contrle. La root
window occupe lensemble de lcran, elle ne peut pas tre redimensionne ou dplace. Chaque
fentre (sauf la root window) a une fentre parente et peut avoir des fentres filles (sous-fentres).
X impose peu de restriction sur la taille et la position des fentres, mais seule les parties de sousfentres qui intersectent avec leur fentre parente sont visibles.

Le systme de fentres X Window

Pierre-Alain Muller

Parent

Child

Il est possible dempiler les fentres de mme rang ( siblings ). La fentre du dessus cache alors
les parties des fentres du dessous avec lesquelles elle intersecte. Lordre dempilement peut tre
altr entre fentres de mme rang. Du point de vue de lutilisateur, les descendants dune fentre
font surface en mme temps que la fentre parente.
Root Window
WA

WC

WB

WD

WE

WG

WF
WH

1.4.2. Le systme de coordonnes de X Window


Chaque fentre X possde son propre rfrentiel. Le point haut-gauche porte les coordonnes (0, 0).
La position dune fentre est toujours exprime par rapport la fentre parente.

X
(0, 0)
(50, 100)
X
(0, 0)

Le systme de fentres X Window

Pierre-Alain Muller

Le rfrentiel de chaque fentre bouge avec la fentre, de sorte que les applications peuvent y
placer des sous-fentres indpendamment de la position de la fentre parente.
1.4.3. Rgles de visibilit des fentres
Les fentres ne sont pas ncessairement visible sur lcran ds leur cration. En effet, lallocation
des structures de donnes dans le serveur X, et linvocation des procdures dpendant du matriel
sont disjointes. Une fentre est rendue effectivement visible par lopration map . En fait, une
fentre - mme mappe - peut ne pas tre visible du fait des points suivants :
la fentre est entirement recouverte par une autre fentre
un anctre de la fentre nest pas mapp
la fentre nest pas dispose dans la zone visible dun anctre.
1.4.4. Conservation du contenu des fentres
Comme les fentres peuvent tre recouvertes en tout ou partie tout moment, il faut tre capable de
prserver leur contenu afin de pouvoir le restaurer lorsque la fentre sera de nouveau visible. De
nombreux systmes de fentres enregistrent le contenu de lcran sous la forme dune bitmap ou
raster . Cette approche demande une grande quantit de mmoire pour le serveur X ds lors que
le nombre de fentres augmente.
Dans X, ce sont les applications (les clients) et non le serveur X, qui sont responsables pour la
reconstitution du contenu des fentres. Chaque client doit donc tre prt, tout moment,
redessiner le contenu des fentres quil utilise. Toutefois, certains serveurs X offrent la possibilit
optionnelle denregistrer des rasters. Cette technique est connue sous lappellation de backing
store , mais ne peut tre considre comme toujours disponible, et les clients doivent donc toujours
tre capables de reconstruire le contenu des fentres.
1.5. Les vnements
Le serveur X communique avec ses clients par lintermdiaire de messages asynchrones appels
vnements. Les vnements sont gnrs directement, ou indirectement, suite aux manipulations
effectues par les utilisateurs (frappe dune touche du clavier, mouvement de la souris, click de
bouton, ...). Le serveur gnre galement des vnements pour informer les clients des changements
relatifs aux fentres. Par exemple lorsque le contenu dune fentre doit tre restaur, le serveur
gnre un vnement expose . X possde 33 types dvnements et offre un mcanisme qui
permet aux clients de dfinir de nouveaux vnements.
En plus des vnements lis aux fentres, X permet de traiter des vnements de type chiens de
garde par la procdure XtAddTimeOut (interval, proc, data) , et galement de sabonner
des arrives dinformation sur des descripteurs de fichiers au moyen de la procdure XtAddInput
(source, condition, proc, client_data).

Le systme de fentres X Window

Pierre-Alain Muller

Le serveur envoie les vnements dans une file associe chaque client. Chaque vnement
regroupe le type de lvnement, lidentification de la fentre concerne et ventuellement des
donnes spcifiques chaque type dvnements.
La plupart des applications X sont contrles par les vnements ( event-driven ) cest--dire
quelles sont conues pour attendre des vnements et les traiter squentiellement. Ce modle est
particulirement bien adapt pour les applications inter-actives, car il laisse le contrle lusager.
Une application peut galement envoyer un vnement ( une autre application par exemple) au
moyen de la procdure XSendEvent (display, window, propagate, mask, &event).
Liste des vnements de X :
ButtonPress, ButtonRelease, MotionNotify, MapNotify, EnterNotify, FocusIn,
LeaveNotify, FocusOut, Expose, GraphicsExpose, NoExpose, VisibilityNotify,
KeyPress, DestroyNotify, UnmapNotify, MapRequest, ReparentNotify, ResizeRequest,
ConfigureNotify, GravityNotify, CirculateNotify, CirculateRequest,
PropertyNotify, SelectionClear, KeymapNotify, SelectionNotify, ColormapNotify,
ClientMessage, MappingNotify, SelectionRequest, KeyRelease, ConfigureRequest,
CreateNotify

1.6. Le gestionnaire de fentres


Le gestionnaire de fentres ( window manager ) est une application particulire, qui permet un
utilisateur de contrler la taille et la position des fentres sur lcran. Un gestionnaire de fentre est
un client comme un autre, mais il fait appel certaines fonctionnalits du serveur X spcifiquement
conues pour la gestion des fentres. Par exemple, un GDF peut demander au serveur X de lui
passer tous les vnements lis la structure des fentres. Si une application demande de
mapper une fentre, et si un GDF manifest son intrt pour ce type dvnement, le serveur X
envoie un vnement MapRequest au GDF, qui peut alors prendre toutes les actions quil jugera
opportunes. Par exemple ajouter un cadre, un titre, des dcorations ; ou encore rarranger les autres
fentres ( tiling window manager ), mais aussi refuser de montrer la fentre.
La gestion des fentres est une tche complexe qui affecte la fois linteraction entre les
applications et lusager et entre les applications elles-mmes. Le documents ICCCM (Inter Client
Communication Conventions Manual) dfinit le protocole que les GDF et les applications devraient
suivre pour leurs interactions.
Les GDF les plus connus sont wm, uwm (Ultrix wm), awm (Ardent wm), twm (Toms wm), rtl
(tiled wm de Siemens Research Technology Laboratory), et surtout mwm (Motif wm).
1.7. La programmation avec X Window
La dfinition formelle de X est donne en termes du protocole de communication utilis pour
connecter les applications aux stations de travail. Ce protocole est dcrit dans X Window System
Protocol, Version 11 et est gnralement disponible en machine dans la bande de distribution du
M.I.T. sous doc/Protocol/spec . Ce protocole est difficile lire (formel) et de fait, linterface la
plus populaire vers X est la Xlib crite en C. Cette interface dfinit un ensemble de
7

Le systme de fentres X Window

Pierre-Alain Muller

fonctionnalits trs complet pour accder et contrler les crans, les fentres et les dispositifs
dentre.
Nota : Xlib peut tre utilise en Ada par lintermdiaire de Bindings (bibliothque interface)
ou par la Ada Xlib de Gary Barnes.
La programmation dapplications graphiques partir de Xlib est difficile car le niveau dabstraction
de cette bibliothque est trs bas ( assembleur graphique ). Pour simplifier les dveloppements
des interfaces utilisateurs, des botes outils on t construites partir de la Xlib. Citons Interviews
(Stanford), Andrew (Carnegie Mellon), Xray (HP), CLUE (Texas Instruments) et dans notre cas X
Toolkit. X Toolkit se dcompose en deux couches : Xt Intrisincs et les Widgets. En fait, Xt sert de
base de nombreux jeux de widgets aux fonctionnalits identiques mais lapparence diffrente.
Motif dfinit un ensemble de widgets conus pour tre intgrs facilement avec Xt et Xlib de sorte
que les clients peuvent (et souvent doivent) utiliser simultanment les trois niveaux de logiciel.

Application

Widget Set
Xt Intrinsics

X Lib
Network Connection

X Server

2. La programmation avec les botes outils


Toutes les applications X sont normalement conduites par vnements (event-driven). Toutefois, Xt
tend ce modle vers une programmation qui pourrait tre qualifie de distributive ( dispatchdriven ). Avec Xlib, les vnements sont traits par une boucle qui contient une instruction
branchement multiple et qui effectue une action particulire suivant le type de lvnement. Cette
boucle se complique notablement lorsque lapplication contient de nombreuses fentres.

Le systme de fentres X Window

Pierre-Alain Muller

Afin de simplifier la boucle dvnements, les Intrinsics encapsulent le processus de distribution


dvnements dans un mcanisme denregistrement de procdures de traitement dvnements,
associs chaque widget ( callbacks et event-handlers ).

Traite-vnements
Widget
Traite-vnements
Widget

Main Loop

Au lieu dcrire une grande boucle qui contient toute la logique du programme, le programmeur se
contente dassocier les traitements appropris chaque widgets. Cette approche simplifie lcriture
des programmes qui peuvent tre rdigs dans un style plus dclaratif (Si A faire B).
2.1. Fonctionnalits de base de Xt
2.1.1. Initialisation des Intrinsics
Etablissement de la connexion avec le (ou les) serveurs X, et allocation des ressources.
XtInitialize (name, class, options, noptions, &argc, argv)

name : le nom du programme ( emacs )


class : la catgorie du programme ( editor ) en fait Emacs .
La convention a volue et la classe est en fait le nom du programme, avec une majuscule. Le
gestionnaire de ressource (dfini plus loin) utilise ces deux informations pour dterminer les
ressources utilises par le programme.
XtInitialize renvoie un TopLevelShell .
2.1.2. Cration des widgets
Les widgets sont des objets graphiques (construits la main) qui regroupent des structures de
donnes complexes avec les oprations applicables sur ces donnes.
Les widgets, limage des fentres X, sont regroups dans une hirarchie dnomme WidgetTree
. La racine de chaque WidgetTree est toujours un Shell Widget . Les shells ont un et un seul
enfant, ils servent denveloppe (de coquille) pour le widget enfant, et offrent linterface avec le
9

Le systme de fentres X Window

Pierre-Alain Muller

GDF. La fentre X associe a un shell widget est fille de la root window. Les applications qui
possdent plusieurs fentres indpendantes doivent crer plusieurs TopLevelShells.

10

Le systme de fentres X Window

Pierre-Alain Muller

2.1.3. "Realization" des widgets


A sa cration, le widget ne possde pas de fentre X associe. Lopration de realization
consiste crer lensemble des fentres X associes un widget. XtRealizeWidget (widget)
ralise galement les widgets enfants du widget spcifi. Normalement, cette opration nest
applique quune fois, directement sur le TopLevelShell.
2.1.4. Enregistrements des " traites-vnements " et des " callbacks "
2.1.4.1. Les traites-vnements
Un traite-vnement est une procdure invoque par les Intrinsics lorsquun type particulier
dvnement se produit au sein dun widget. Le programmeur de widget peut traiter tout ou partie
des vnements X. Le programmeur dapplication (le client du programmeur prcdent) peut
enregistrer des traites-vnements additionnels laide de la procdure
XtAddEventHandler (widget, eventmask, nonmaskable, handler, client_data)

La forme gnrale dun traite-vnement est comme suit :


void handler (w, client_data, event)
Widget
w;
caddr_t
client_data;
XEvent
*event;
caddr_t

=>

untyped pointer

ex: typedef caddr_t

char *

2.1.4.2. Les Callbacks


Les widgets peuvent galement dfinir des points dentre, ou crochets, que les applications
peuvent utiliser pour spcifier le traitement devant tre effectu lors de loccurrence dune
condition donne (matrialise par un vnement). Ce mcanisme est connu sous lappellation de
callback , car linterface (le widget) effectue un appel (rappel) de procdure vers lapplication,
cest--dire vers du code non connu lors de lcriture du widget. Chaque widget possde une liste
de callbacks pour un type daction donn.
Call Direct
Application

Exemple :

Call Back

Widget

Callback List

tout widget possde XtNdestroyCallback


pour un bouton

XmNactivateCallback, XmNarmCallback,
XmNdisarmCallback

11

Le systme de fentres X Window

Pierre-Alain Muller

2.1.4.3. Diffrence entre un callback et un traite-vnement


Le callback est plus abstrait, il nest pas attach un vnement mais une action. Dautre part,
lutilisateur peut personnaliser laction qui dclenche le callback grce au translation manager .
vnement => tripes du widget

callback => interface du widget

2.1.5. La distribution des vnements


La programmation par vnements partir de Xlib seule est fastidieuse car toute la logique du
programme est concentre dans la boucle principale. Xt simplifie considrablement la boucle
principale, qui se rsume en lappel de la procdure XtMainLoop (). La boucle principale contient
le code suivant :
While (TRUE)
{
XEvent event;
XtNextEvent (& event);
XtDispatchEvent (& event);
}

Chaque application possde une file dvnements remplie par le serveur X. XtNextEvent rcupre
un vnement, puis XtDispatchEvent part la recherche du traite vnement correspondant.
Il est possible dinsrer un traitement supplmentaire dans la boucle dvnements, lorsque
lapplication dsire prendre la main de temps en temps, par exemple pour effectuer des tches non
interactives. La fonction non bloquante XtPending() permet de savoir si la file dvnements est
vide.
While (TRUE)
{
if (XtPending ())
{
XtNextEvent (& event);
XtDispatchEvent (& event);
} else
.....
}
}

2.1.6. Le "Translation Manager"


Le Translation Manager de Xt permet lutilisateur de spcifier (sans reprogrammation de
lapplication ) les associations entre les actions de lusager et les oprations dclencher. Voici par
exemple, comment modifier laction dun bouton poussoir dans lapplication memo .
Dans le fichier .Xdefaults :
memo*XmPushButton.translations:<key>q:ArmAndActivate()

12

Le systme de fentres X Window

Pierre-Alain Muller

De faon gnrale, une table de translation contient une liste dexpressions qui possdent chacune
une partie gauche et une partie droite, spares par un double point. La partie de gauche spcifie
laction de lusager et la partie de droite la procdure excuter.
*translations:<Btn1Down>, <Btn1Up>:ArmAndActivate()
*translations:Ctlr<Btn1Down>:ArmAndActivate()

Les applications peuvent ajouter leurs propres action en utilisant la procdure :


XtAddActions (actions, num_actions)

3. Le gestionnaire de ressources de X
Les ressources sont toutes les informations personnalisables par lusager. Par convention, les
applications X devraient permettre la personnalisation de la plupart des donnes utilises, tout en
offrant des valeurs par dfaut raisonnables. En fait, lutilisateur peut personnaliser les ressources
sil le dsire, mais il nest pas oblig de le faire. Notons que le programmeur doit faire un effort
pour rendre lapplication personnalisable, ce nest pas compltement automatique.
3.1. Spcification des ressources
X maintient une base de donnes qui contient la fois les prfrences des utilisateurs et les valeurs
par dfaut. Les applications peuvent retrouver la valeur dune ressource, durant leur excution, en
questionnant le gestionnaire de ressources. Le GDR se distingue des SGBD traditionnels, car il
contient des informations gnrales sur les ressources, du genre Tous les boutons sont rouges ou
Tous les champs de saisie de texte sont long de 80 caractres . Par contre les requtes sont
prcises : Couleur du bouton Quit de lapplication mail ? .
3.1.1. Noms et classes des ressources
Chaque ressource possde un nom et une classe. Par exemple : emacs et
Editor ,
destroyCallback et Callback . Les noms et les classes des ressources sont des chanes de
caractres, les valeurs les plus utilises sont dfinies dans le fichier StringDefs.h . Il est possible
dajouter de nouveaux noms et de nouvelles classes de ressources.
Par convention, le nom des ressources commence par une lettre minuscule, alors que le nom des
classes commence par une majuscule. Frquemment, les noms de ressource et de classe sont
identiques, sauf pour la premire lettre capitale. La nom de classe est fixe par le programmeur du
widget, le nom de ressource (en fait de widget) est dtermin par le programmeur de lapplication.
Une application rcupre la valeur dune ressource en spcifiant prcisment la ressource dsire,
sous la forme dun chemin daccs au travers de larbre de widgets (spars par des points).

13

Le systme de fentres X Window

Pierre-Alain Muller

draw
(Draw)
panel
(XmBulletinBoard)
commands

canvas

options

(XmRowColumn)

(XmDrawingArea)

(XmRowColumn)

button1 button2 button3


(XmPushButton)

button1 button2 button3


(XmPushButton)

nom de ressource (un widget particulier) :


draw.panel.commands.button1.foreground: orangeRed

nom de classe (un ensemble de widgets) :


Draw.XmBulletinBoard.XmRowColumn.XmPushButton.Foreground: red

3.1.2. Algorithme de substitution de noms


La spcification complte des chemins daccs est fastidieuse, pour cette raison le RM de X dfinit
le caractre spcial * qui peut reprsenter un ou plusieurs noms de ressources ou de classes.
Exemple :
draw*foreground: darkSlate
*XmPushButton.foreground: mediumAquamarine

Notons que lon peut mlanger noms de ressources et noms de classes.


3.1.2.1. Rgles de prcdence
1_ Chaque nom de ressource ou de classe dans le chemin doit correspondre une entre dans la
base de donnes.
2_ Le "." est prioritaire par rapport au * car il est plus spcifique.
*commands.Background: green

*commands*Background: red

3_ Le nom de ressource est prioritaire par rapport au nom de classe.


4_ Les noms de ressource et de classe sont prioritaires par rapport au caractre de substitution * .

14

Le systme de fentres X Window

Pierre-Alain Muller

5_ Le RM compare les entres de la gauche vers la droite, et les premiers lments sont prioritaires
par rapport aux suivants.
draw*XmBulletinBoard*foreground: green

est prioritaire par rapport :


draw*XmPushButton*foreground: red

Conclusion : cest un peu difficile lorsque le nombre de ressources est lev ! Cela peut aussi
prendre du temps lors du dmarrage de lapplication.
3.1.3. Chargement des ressources
Les ressources sont charges lors du dmarrage de lapplication, dans lordre suivant :
1_

/usr/lib/X11/$LANGapp-defaults/<class>

2_

/usr/lib/X11/app-defaults/<class>

3_

$XAPPLRESLANGPATH<class>

4_

$XAPPLRESDIR<class>

5_

RESOURCE_MANAGER property

6_

$HOME/.Xdefaults

7_

$XENVIRONMENT

8_

$HOME/.Xdefaults-<hosts>

9_

la ligne de commande ...

// si 1 choue

// si 3 choue

// si 5 n'existe pas

// si 7 n'existe pas

3.1.4. Ressources et conventions


Les ressources dfinies par le programmeur sont prioritaires par rapport aux ressources dfinies par
lutilisateur. Parfois, il est difficile de savoir qui devrait positionner une ressource ; une bonne rgle
est de ne fixer que les ressources ncessaires la bonne marche de lapplication.
Exemple : ne pas permettre de transformer le label du bouton delete en save . Hlas, ce nest
pas si simple, car dans ce cas on ne peut plus personnaliser la langue. Une bonne approche consiste
livrer lapplication avec un fichier de ressources que lutilisateur peut modifier sa guise.
Plus une application est personnalisable, plus elle est mme de satisfaire les gots et les couleurs
de lutilisateur? Toutefois, il ne faut pas tomber dans le travers de forcer lutilisateur
personnaliser. Par dfaut, lapplication doit comporter un assortiment de ressources
raisonnablement positionnes.

15

Le systme de fentres X Window

Pierre-Alain Muller

4. Les couleurs
X propose un modle qui dissimule la diversit des matriels daffichage derrire une interface
commune. Cette approche permet de construire des applications versatiles, qui fonctionnent de
faon satisfaisantes sur des crans noirs et blancs, en niveaux de gris, ou couleur.
X est conu pour les environnements multitches, cest--dire des systmes qui demandent le
partage des crans entre plusieurs applications. Cette contrainte complique considrablement le
modle des couleurs, car un cran donn ne peut afficher quun nombre limit de couleurs
simultanment, et les diffrentes applications devront donc se partager les couleurs disponibles un
moment donn.
Une approche simple consiste limiter le nombre total de couleurs disponibles. Cest la solution
retenue sur des ordinateurs rudimentaires (choix entre 8 ou 16 couleurs prdfinies).
Cette solution nest pas satisfaisante pour construire un environnement graphique de qualit, cest
pourquoi X se distingue en proposant une technique qui permet chaque application dallouer
autant de couleurs que ncessaire, tout en encourageant le partage de couleurs entre applications.
4.1. Les tables de couleurs (colormaps)
X utilise des colormaps , cest--dire des tableaux qui contiennent des couleurs. Les applications
accdent aux couleurs par lintermdiaire dun index dans la colormap. La colormap introduit une
indirection entre lindex utlis par les applications et la couleur affiche sur lcran. Les crans
possdent une profondeur, exprime en nombre de bits par pixel (on parle galement de plans
dcran). Un cran monochrome possde une profondeur de 1 bit. Le nombre de couleurs quun
cran peut afficher simultanment est donne par la relation couleurs = 2 plans.
Diffrentes applications peuvent partager la mme table des couleurs. Par dfaut, les fentres
hritent de la table de leur parent et la plupart des applications peuvent utiliser la table de la root
window. Cette colormap est appele default colormap . Le serveur y alloue deux couleurs, le
blanc et le noir ; les autres couleurs y seront rajoutes par les applications qui le dsirent. Une
application qui ncessite un grand nombre de couleurs peut crer une nouvelle colormap, diffrente
de la colormap par dfaut. La fonction
XInstallColormap (display, map)

permet de positionner la colormap par dfaut, et donc den changer selon les besoins. Toutefois,
lorsque seulement une application a besoin dune colormap particulire, la fonction
XSetWindowColormap (display, window, cmap)

permet dassocier une colormap avec une fentre (et ses enfants par hritage).
5. Les images

16

Le systme de fentres X Window

Pierre-Alain Muller

En plus des images visibles lcran, X offre des trois catgories dimages non visibles : les
pixmaps , les bitmaps et les Ximages .
5.1. Les pixmaps
Une pixmap est une zone de mmoire similaire une rgion rectangulaire de lcran, mais sans
correspondance visible. Les pixmaps ont une profondeur exprime en bits. La fonction
XCreatePixmap (display, drawable, width, height, depth)
cr une pixmap associe avec le mme cran que le drawable spcifi. Les pixmaps servent
principalement pour sauvegarder le contenu de fentres. Les pixmaps peuvent galement tre
utilises pour construire des images de fond partir de petits motifs lmentaires (tiles de 16x16).
5.2. Les bitmaps
Les bitmaps sont des pixmaps avec une profondeur de 1. Elles peuvent tre cres par la fonction
XCreateBitmapFromData (display, drawable, data, width, height)

Les donnes tant des sries de bits qui reprsentent la valeur de chaque pixel. Lditeur bitmap,
livr avec X, permet de construire des fichiers bitmaps directement exploitable par la fonction
prcdente.
5.3. Les Ximages
X offre un mcanisme de transfert dimages entre applications et le serveur X, par lintermdiaire
dune structure de donnes Ximage. Cette structure sauvegarde les informations dans une
reprsentation canonique, indpendante des particularits de chaque machine. Lallocation dune
Ximage seffectue par la fonction
XCreateImage (display, visual,
bitmap_pad, bytes_per_line)

depth,

format,

offset,

data,

width,

height,

les images peuvent galement tre extraites dun drawable par la fonction
XGetImage (display, drawable, x, y, width, height, plane_mask, format)

5.4. Copie entre drawables


Le contenu dun drawable (une fentre, une pixmap) peut tre copi vers nimporte quel autre
drawable de la mme profondeur, par la fonction
XCopyArea (display, src, dest, gc, src_x, src_y, width, height, dest_x, dest_y)

La fonction suivante permet de copier entre drawable de profondeurs diffrentes


XCopyPlane (display, src, dest, gc, src_x, src_y, width, height, dest_x, dest_y,
plane)

17

Le systme de fentres X Window

Pierre-Alain Muller

Le contexte graphique dtermine lavant-plan et larrire-plan du drawable destination.

18

Le systme de fentres X Window

Pierre-Alain Muller

6. Les contextes graphiques et les rgions


Les applications graphiques ncessitent des informations de description comme la largeur des
lignes, les couleurs davant-plan et darrire-plan, les fontes, les formes de remplissage, ...
6.1 Les contextes graphiques
Tous les attributs graphiques sont stocks par X dans une structure de donnes interne appele
graphic context . Une application peut crer puis manipuler plusieurs contextes graphiques.
XCreateGC (display, drawable, mask, &values)
XtGetGC (widget, mask, values)
// prvue pour le partage de
// GC entre applis
values est de type XGCValues, une structure qui contient une vingtaine de membres.
mask indique quel(s) membres contiennent une information utile. Un masque nul entrane la

cration dun GC avec des valeurs par dfaut.


Les contextes graphiques sont alors passs en paramtres toutes les oprations qui dessinent ou
qui crivent.
ex : XDrawString (display, drawable, gc, x, y, str, length)
6.2. Les rgions
Les rgions permettent de reprsenter et de manipuler des zones non-rectangulaires. Les rgions
sont surtout utilises lors des oprations de rafrachissement de lcran, par exemple pour
dterminer quelles parties dune image doivent tre reconstruites. Une rgion encapsule des
donnes qui ne peuvent tre manipules que par lintermdiaire doprations prdfinies. Ces
oprations sexcutent localement dans le client, sans faire de requtes au serveur X. Xlib fournit
des primitives pour crer, comparer et dtruire les rgions.
Les rgions sont utilises par certains widgets qui exigent que les Intrinsics compressent les
vnements de type expose.
7. Le texte et les fontes
Xlib offre un ensemble de primitives pour dessiner du texte dans des fentres ou des pixmaps (zone
de mmoire identique une fentre, mais non visible lcran). Motif rajoute une abstraction
dnomme compound string pour reprsenter du texte indpendamment des modes de
reprsentation.
7.1. Les fontes
Une fonte est une collection de bitmaps rectangulaires, dnommes glyphs . Un glyph peut
contenir nimporte quelle image, de sorte que certaines fontes ne contiennent pas des caractres
19

Le systme de fentres X Window

Pierre-Alain Muller

alphabtiques. Les fontes doivent tre charges pour tre disponibles (une fonte consomme des
ressources). La fonction XLoadFont (display, font_name) charge la fonte et retourne un
identificateur de fonte. Chaque fonte est dcrite par une structure de donnes XFontStruct qui peut
tre rcupre par la fonction XQueryFont (display, font_ID). Cette structure contient :
lidentificateur de la fonte, la direction (gauche ou droite), lencombrement du plus petit caractre,
lencombrement du plus gros caractre, la hauteur par rapport la ligne de base, la profondeur par
rapport la ligne de base, et un tableau de XCharStruct qui dcrit chaque caractre en dtail.
Cette structure contient entre autres les informations suivantes :
short
short
short
short
short

lbearing;
rbearing;
width;
ascent;
descent;

g
Des fonctions de Xlib (comme XTextWidth ou XTextExtents) permettent dobtenir des
informations sur lencombrement global de chanes de caractres.
7.2. Lcriture du texte
X affiche le texte dans un drawable au moyen des fonctions suivantes :
XDrawString (display, drawable, gc, x, y, str, length) //foreground only

et
XDrawImageString (display, drawable, gc, x, y, str, length)

7.3. Les chanes composites


Motif offre un mcanisme pour la reprsentation du texte de manire plus abstraite que la chane de
caractre. Les chanes composites sparent le contenu de la forme. Une chane composite est
constitue de trois parties :
le jeu de caractre (le nom de la fonte)
la direction (par dfaut de gauche droite)
20

Le systme de fentres X Window

Pierre-Alain Muller

le texte lui mme.

21

Le systme de fentres X Window

Pierre-Alain Muller

Motif fournit de nombreuses fonctions pour manipuler les chanes composites, comme :
XmStringCreate, XmStringLtoRCreate, XmStringFree, XmStringSeparatorCreate,
XmStringCompare, XmStringEmpty, XmStringConcat, XmStringLength

ou pour les afficher :


XmStringDraw et XmStringDrawImage.

8. La structure des widgets


Les Intrinsics dfinissent larchitecture de base des widgets. Le but est de faciliter lintgration de
widgets de diffrentes provenances au sein de la mme application.
Les widgets sont organiss en classes, elles mmes organises en hirarchie. Chaque widgets
comporte deux composants : les informations de classe ( class record ) et les informations
dinstance ( instance record ). Les Intrinsics sont cods en langage C de sorte que lhritage doit
tre simul la main. Chaque widget est ralis sous la forme dune structure qui contient des
donnes et des pointeurs vers les oprations. Les widgets dune mme classe partagent les donnes
et les oprations de leur classe, et possdent leur propre copie des donnes spcifiques chaque
instance.
La description de classe est alloue et initialise statiquement, la partie propre aux instances est
alloue la demande, lors de lexcution.
8.1. Les informations de classe
Les informations de classe (class record) regroupent les donnes et les oprations qui sont
communes tous les widgets (les objets) de la classe. Il sagit essentiellement de donnes statiques
comme par exemple le nom de la classe, lapparence ou le comportement en gnral.
Tous les widgets hritent de la class Core qui dfinit entre autres les informations de classe
suivantes :
le nom de la superclasse, le nom de la classe, la taille du widget, les actions, les ressources, la
version des Intrinsics, ...
ainsi que des mthodes pour linitialisation, la ralisation, le re-dimensionnement, la destruction, le
rafrachissement, ...
8.2. Les informations dinstances
Chaque widget contient des informations sur son tat. Les widgets, qui hritent tous de la classe
Core, contiennent entre autres les informations dinstances suivantes :
un pointeur vers self, un pointeur vers la classe, un pointeur vers le parent (celui qui le contient), un
nom, lidentificateur de la fentre X associe, la position, la taille, ...
22

Le systme de fentres X Window

Pierre-Alain Muller

23

Le systme de fentres X Window

Pierre-Alain Muller

8.3. Encapsulation des donnes


Les applications qui utilisent les widgets ne voient pas leur implmentation. Les Intrinsics
dfinissent une double dfinition pour chaque widget, une vision prive pour le constructeur du
widget, et une vision public pour lutilisateur. Loccultation dinformation est ralise en organisant
limplmentation du widget en diffrents fichiers. Chaque widgets est construit partir de un ou
plusieurs fichiers dentte privs ( private header files ), un fichier dentte public ( public
header file ), et un ou plusieurs fichiers de source C. Le fichier dentte priv contient toutes les
dfinitions ncessaires pour la construction du widget, alors que le fichier public ne contient que les
dfinitions ncessaires pour lutilisation du widget.
8.4. Les widgets de Motif
Core..XmPrimitive..
XmArrowButton
.
XmLabel....... XmCascadeButton
.
.
XmDrawnButton
.
.
XmPushButton
.
.
XmToggleButton
.
XmList
.
XmSash
.
XmScrollBar
.
XmSeparator
.
XmText
.
Composite.... Shell....OverrideShell...XmMenuShell
.
TransientShell..XmDialogShell
.
Constraint... XmManager...XmBulletinBoard.XmForm
.
XmMessageBox
.
XmSelectionBox
.
XmCommand
.
XmFileSelectionBox
XmDrawingArea
XmFrame
XmRowColumn
XmScrolledWindow .... XmMainWindow
XmScale
XmPanedWindow

Conclusion
X est un bon exemple de systme de fentres, mais il devient de plus en plus complexe.
X est ouvert, extensible.
Par X on entend plutt Xlib, Xt Intrinsics, Motif, ...
La programmation reste difficile, il faut saider de constructeurs dinterfaces.

24