\documentstyle[12pt,a4]{article} \title{Graphics developments} \author{L.Michel \& G.Zehnacker} \date{Edition 1.1 4 June 1991} \begin{document} \begin{titlepage} { \hoffset=0truein \hsize=6.25truein \vsize=10.25truein \font\small=cmssbx10 at 14.4truept \font\medium=cmssbx10 at 17.28truept \font\large=cmssbx10 at 20.74truept \hrule height 0pt \parindent=0pt %\parskip=0pt \hskip 3.9truein \large \par \vskip .5truein \large Eurogam project\hspace{5cm}EDOC118\par \vskip 1.5truein \hrule height 2pt \vskip 20pt \large Graphics developments\par \vskip .5truein Principles and architecture \par \vskip 20pt \hrule height 2pt \vskip 1truein \rm \small \begin{tabbing} edition \=: 1.1\\ date \>: 4 June 1991\\ auteurs \>: G.Michel \& G.Zehnacker\\ \end{tabbing} \vfill \bf \medium Centre Recherches Nucleaires Strasbourg \par \vskip 5pt CNRS-IN2P3 France \par \vskip .5truein } \end{titlepage} \maketitle \begin{center} Abstract \end{center} \vskip 1cm \hskip 1cm Apr\`{e}s la rencontre avec nos coll\`{e}gues de Daresbury (15-16-17 janvier) \`{a} Strasbourg, nous avons mis en forme et approfondit les id\`{e}es concernant le graphique . Dans le cadre de la collaboration Eurogam seront developp\'{e}es de nouveaux logiciels notamment graphiques. Ceux ci devront \^{e}tre construits avec les m\^{e}mes id\'{e}es de base et comporter un 'look' identique \`{a} Daresbury et Strasbourg de telle fa\c{c}on que le physicien passe sans difficult\'{e} d'une interface graphique \`{a} l'autre . \hoffset=0truein \hsize=6.truein \vsize=10.25truein \vskip 15cm \newpage \section{Introduction} \subsection{Pourquoi un nouveau logiciel graphique ?} \hskip 1cm Les laboratoires du NSF de Daresbury et du CRN de Strasbourg dispose actuellement de logiciels graphiques qui doivent \^{e}tre revus pour satisfaire aux exigences du multid\'{e}tecteur Eurogam et des demandes pr\'{e}cises des physiciens. A Strasbourg , les nouveaux logiciels doivent aussi satisfaire aux demandes des autres acquisitions aupr\`{e}s du Vivitron avec Demon, Icare et les Multicompteurs au Q3D. \subsection{Ecran de pr\'{e}sentation} Au d\'{e}marrage l'\'{e}cran se pr\'{e}sentera sous la forme de la figure 1 o\`{u} plusieurs logiciels seront disponibles aux physiciens, Il suffira de cliquer dans une des cases pour le selectionner. \bf ( voir figure 1 )\rm \section{Pr\'{e}sentation de l'architecture} \subsection{Quelques principes} Nous allons pr\'{e}ciser les principes suivis pour concevoir le nouveau logiciel graphique qui sont : \begin{itemize} \item de d\'{e}velopper sur des stations de travail connect\'{e}es en r\'{e}seau \-ether\-net \item de dialoguer avec les logciels par clavier et souris \item d'adapter les logiciels pour qu'ils soient appelables \`{a} partir par des terminaux classiques ( type tektro ou falco) \item de tenir compte des nouveaux outils de developpement disponibles (notamment Dev guide sur SUN voir EDOC116) \item de tenir compte des biblioth\`{e}ques graphiques (xlib sous X-Window version x11R4) pour tracer les spectres \item d'utiliser des biblioth\`{e}ques appel\'{e}es toolkit interm\'{e}diaires entre la xlib et l'application pour cr\'{e}\'{e}r boites de dialogue , boutons , menus etc \item de permettre \`{a} l'utilisateur d'adapter lui m\^{e}me le soft \`{a} ses besoins (avec le moins de recompilation possible) \item de tenir compte des possibilit\'{e}s des nouveaux mat\'{e}riels et logiciels de base . \item de r\'{e}utiliser les fonctions d'analyse qui ne changent pas \end{itemize} \subsection{Cadre de l'\'{e}tude} Une premi\`{e}re proposition d'interface graphique avec quelques fonctions d'analyse a \'{e}t\'{e} propos\'{e}e dans EDOC112. Une approche d'architecture interne est pr\'{e}sent\'{e}e dans EDOC110. Dans le pr\'{e}sent article nous en tiendrons compte pour poursuivre nos reflexions et concevoir une architecture interne du nouveau logiciel graphique \bf (voir figure 2)\rm. Celle ci sera tr\'{e}s modulaire et sera alors plus facile \`{a} d\'{e}velopper et \`{a} maintenir. \subsection{Sch\'{e}ma g\'{e}n\'{e}ral} Les commandes demand\'{e}es sont s\'{e}lectionn\'{e}es par l'utilisateur depuis son terminal ou de sa station, puis mise en forme pour \^{e}tre envoy\'{e}es \`{a} un shell qui s\`{e}lectionnera la fonction \`{a} activer \`{a} partir de diff\'{e}rentes librairies . La figure 2 montre \`{a} gauche les diff\'{e}rentes fa\c{c}ons de saisir une commande UNIX: \begin{itemize} \item soit par l'interm\'{e}diaire d'une fen\^{e}tre shell tool sous Open Windows \item soit par un shell sur une console Tektro 4014 (par exemple) \item soit par un interface graphique par l'intermediaire de menu \item soit par un shell sur une console X \end{itemize} Au centre du sch\'{e}ma un shell recevra ces commandes et activera des programmes d'analyse provenant de diff\'{e}rentes librairies \`{a} gauche. \subsection{Diff\'{e}rents niveaux dans le logiciel} Dans notre analyse nous aurons \`{a} l'esprit les principes d\'{e}crits plus haut et les concepts X-Window d\'{e}crits dans l'annexe 1. En allant donc plus au fond des choses, nous d\'{e}composerons le premier sch\'{e}ma propos\'{e} en plusieurs niveaux \bf (voir figure 3) \rm. Ceux ci sont dans l'ordre \`{a} partir d'une action sur le terminal : \begin{itemize} \item un driver de terminal sp\'{e}cifique \`{a} chaque station ou terminal \item un serveur X \item des progammes clients \begin{itemize} \item Xterm, \item Window manager, \item analyse de spectres, \item setup, \item acquisition, \item controle (monitoring) \item test de carte electronique \item analyse de spectres, \item selecteur de logiciel ( voir figure 1) \end{itemize} \item des serveurs fonctionnels \begin{itemize} \item serveur de spectres \item shell \item autres \end{itemize} \item des acc\'{e}s \`{a} des ensembles d'informations sous forme \begin{itemize} \item de librairies de fonctions d'analyse, \item de base de donnees, \item de fichiers de spectres \end{itemize} \end{itemize} \section{Le X server} Ce module est un produit fourni avec tout le logiciel X-Windows du MIT. Nous n'aurons pas \`{a} le modifier. Il prendra en compte toutes les actions faites \`{a} la station (voir annexe 1) et les transmettra \`{a} un client. D'un autre cot\'{e}, il ex\'{e}cutera sur l'\'{e}cran de la station toutes les requ\^{e}tes re\c{c}ues par exemple soit du shell, soit de l'afficheur de spectres ou d'autres clients ( notamment du window Manager) . \section{Diff\'{e}rentes sortes de clients} \subsection{Xterm} C'est lui qui recevra les commandes UNIX . Elles seront transmises \`{a} un shell (Bourne shell ou C-Shell) qui lancera une commande shell, un programme utilisateur ou un script. La tache cr\'{e}\'{e}e par le shell pourra \^{e}tre un programme d'analyse (affichage de donn\'{e}es, int\'{e}gration, fit, recherche de pics, etc ) ou bien une action sur une fen\^{e}tre de spectres. \subsection{Window manager} Le window manager est un client charg\'{e} de la gestion des \'{e}cran des clients. Ce client prend en charge toutes les fonctions de r\'{e}organisation de fen\^{e}tres (ouvrir, fermer, agrandir, faire disparaitre les fenetres , etc ). Ce client tourne sur une machine du r\'{e}seau. Il a en charge l'aspect visuel des fen\^{e}tres. Il peut avoir des liens avec d'autres clients. Il a en charge la gestion des menus apparaissant sur la fen\^{e}tre racine (menu en fond d'ecran) \subsection{Setup} De nombreuses informations sont initialis\'{e}es dans un premier temps, puis modifier ou lister . Ce client serait charg\'{e} de cette fonction de "data base". Naturellement elle ne sera pas accessible de n'importe ou par n'importe qui . Un syst\'{e}me de droit r\'{e}serv\`{e} est \`{a} mettre en place . \bf(voir figure 5)\rm \subsection{Acquisition} Pour param\'{e}trer une experience, la d\'{e}marrer, l'interrompre ou l'arr\^{e}ter nous allons d\'{e}velopper un interface graphique s'int\'{e}grant dans l'ensemble . Ce client disposera aussi de fonctions de contr\^{o}le sp\'{e}cifique graphique d'affichage de spectres . \bf (voir EDOC111 et figure 6)\rm \subsection{Contr\^{o}le} Les dispositifs exp\'{e}rimentaux doivent \^{e}tre surveill\'{e}s en permanence et d\'{e}tecter im\-m\'{e}\-dia\-tement toute panne ou d\'{e}faillance partielle du materiel. Un ou plusieurs clients X assumeront cette fonction. \bf (voir figure 7) \rm \subsection{Test} Ce logiciel permettra d'afficher des synoptiques de cartes (par ex GE, BGO ou trigger, etc), d'indiquer une connexion entre un composant et une des 4 entr\'{e}es d'un oscilloscope externe. Il sera aussi possible de visualiser le spectre d'une voie et de modifier \`{e}ventuellement quelques param\`{e}tres fournis \`{a} des composants electroniques. Un EDOC est en cours de redaction. \bf(voir figure 8)\rm \subsection{L'analyseur des spectres} Il aura en charge toutes les fonctions n\'{e}cessaires pour g\'{e}rer l'espace d'affichage des spectres, de prendre en charge toutes les commandes "Scope" pour parametrer le dessin \`{a} l'ecran , dessiner les spectres et d'activer les fonctions d'analyse . \bf voir Edoc 112 et figure 9\rm \subsection{Le client "menu"} Il recevra du X server un \'{e}venement pr\'{e}\c{c}isant fonctionnellement le nom de l'option selectionn\'{e}e par la souris. Cette option devra \'{e}ventuellement \^{e}tre complet\'{e}e par une saisie de donn\'{e}es par boite de dialogue. Apr\`{e}s mise en forme de ces renseignements sous forme d'un message , ils seront transmis vers un programme charg\'{e} d'executer les commandes. \section{Serveur de fonctions} \subsection{Le serveur de fonctions d'analyse} ce module est en fait un shell UNIX qui sera appel\'{e} par le client menu qui lui fournira le nom du programme et de ces param\`{e}tres. Le dialogue s'etablit alors directement entre programme fonction et client menu. \subsubsection{Le serveur de spectres} Ce module est charg\'{e} de rechercher les spectres sur le r\'{e}seau pour le compte d'un client qui pourra \^{e}tre par exemple l'afficheur de spectres ou un module appel\'{e} par le shell. La demande de spectre(s) se fera \`{a} travers une boite de dialogue apparaissant \`{a} l'\'{e}cran qui demandera le nom de la machine, du r\'{e}pertoire et des fichiers spectres ou du numero du device bande. Cette information permet au serveur de rechercher le spectre au bon endroit et de le faire parvenir au demandeur de spectres. \section{Les librairies} \subsection{De fonctions} Cette librairie contient toutes les fonctions d'analyse developp\'{e}es au cours des ann\'{e}es et qui seront r\'{e}utilisables. La contrainte est qu'il faut y toucher le moins possible. Il faut donc respecter ce que demandent ces fonctions en entr\'{e}e et ce qu'elles restituent en sortie. Nous imaginerons donc une boite de dialogue aussi universelle que possible pour l'entr\'{e}e des donnees et mini fen\^{e}tre d'affichage. Cela permettra donc une entr\'{e}e de commandes parametr\'{e}es beaucoup plus conviviales qu'avec un Bourne shell ou un C-shell. L'appel de fonctions par menu devra suivre le m\^{e}me m\'{e}canisme. \subsection{De donn\'{e}es ( data base)} Les \'{e}tudes sont en cours pour soit choisir un produit disponible(free share) soit en developper un specifiquement pour Eurogam. \subsection{De spectres} Un logiciel d'acc\'{e}s fournira les fonctions d'\'{e}criture, de lecture et de recherche de spectres. Nous rappelons que les spectres seront stock\'{e}s soit en m\'{e}moire de l'histogrammer, soit sur une bande exabyte ou un disque situ\'{e} sur une station du r\'{e}seau. \section{Description du protocole entre modules} La \bf figure 4 \rm montre qu'un client pourra \^{e}tre en relation avec un certain nombre de mo\-dules. Sous le terme module nous entendrons \`{a} la fois les progammes clients (au sens de X-Window) ainsi que les serveurs de fonctions. Tous ces modules vont avoir \`{a} communiquer entre eux. Ces informations seront de type tres diff\'{e}rent par exemple \begin{itemize} \item des appels \`{a} des programmes avec une liste de parametres \item des informations re\c{c}ues de ces programmes qui sont \`{a} afficher \item des positions de curseur sur l'\'{e}cran \item des positions de canal selectionn\'{e}s sur un spectre \item des tableaux de chaines de caracteres par ex des listes de noms de spectres \item des positions de pics \`{a} materialiser avec leurs caracteristiques \item des actions demandees pour modifier l'affichage des spectres \item des modifications des fen\^{e}tres \item etc \end{itemize} \subsection{appel au librairies externes} \hskip 1cm Le projet a \'{e}t\'{e} d\`{e}s le d\'{e}but defini comme pouvant utiliser des fonctions externes appel\'{e}es \`{a} partir d'un noyau graphique fig\'{e}. Il a \'{e}t\'{e} convenu que la connection d'une librairie externe au logiciel graphique devait pouvoir se faire sans recompiler ce dernier. Par ailleurs, les fonctions externes doivent pouvoir etre utilis\'{e}es dans d'autres contextes que nos logiciels graphiques. La prise en compte d'une fonction externe peut se d\'{e}composer en quatre \'{e}tapes: \begin{itemize} \item Param\'{e}trage de la fonction (proc\'{e}dure interne au logiciel graphique). \item Appel de la fonction (utilisation du syst\`{e}me d'exploitation). \item Retour des r\'{e}sulats (utilisation du systeme d'exploitation). \item Prise en compte des r\'{e}sultats (procedure interne au logiciel graphique). \end{itemize} A chacune de ces \'{e}tapes correspond une proc\'{e}dure particuli\`{e}re developp\'{e}e dans un EDOC11x en cours de r\'{e}daction.. Il nous est apparu n\'{e}cessaire de pouvoir appeler ces proc\'{e}dures externes \`{a} partir du shell (ligne de commande). Cela impose aux fonctions externes de se pr\'{e}senter comme des fichiers ex\'{e}cutables. Une modification d'un de ces executables n'entrainera aucune modification au logiciel graphique d'analyse. \subsection{Param\'{e}trage des fonctions} \hskip 1cm Chaque fonction externe demande un param\'{e}trage propre. Ce dernier est realis\'{e} \`{a} partir du noyau graphique qui doit donc \^{e}tre capable de saisir des arguments divers sans \^{e}tre recompil\'{e}. La solution la plus simple consisterait \`{a} demander \`{a} l'utilisateur de taper directement la ligne de commande. Cette solution pour simple qu'elle soit, n'est pas satisfaisante car, d'une part, elle demande \`{a} l'utilisateur la connaissance d'une syntaxe et d'autre part, elle nous fait perdre le b\'{e}n\'{e}fice de l'interface graphique. Nous pr\'{e}ferons nous reporter vers l'utilisation de boites de dialogue parametrables. Ces boites de dialogue sont cr\'{e}\'{e}es dynamiquement \`{a} partir d'objets actifs tels que des boutons ou des \'{e}diteurs de ligne de texte. Il est donc ais\'{e} d'associer \`{a} chaque fonction externe la boite de dialogue utilis\'{e}e pour son param\'{e}trage. Le param\'{e}trage de la fonction se fait en associant un param\`{e}tre \`{a} chaque \'{e}lement actif de la boite de dialogue, puis en d\'{e}finissant l'ordre des param\`{e}tres \`{a} passer de maniere \`{a} pouvoir merger la ligne de commande. Ces informations devrons se trouver dans un fichier, lu par le noyau graphique au moment de son d\`{e}marrage. De la sorte, il suffira de cr\'{e}\`{e}r un fichier pour chaque librairie. \subsection{Appel des fonctions} \hskip 1cm Le noyau graphique doit cr\'{e}\'{e}r le processus correspondant \`{a} l'execution de la fonction. Ce processus voit sa sortie redirig\'{e}e vers le noyau graphique afin de lui transmettre le resultat de ses calculs. Pour ce faire, nous proposons d'utiliser les 'pipes' Unix. \subsection{Retour des r\'{e}sultats} \hskip 1cm Les fonctions externes se pr\'{e}sentent sous la forme de fichiers executables, leurs r\'{e}sultats sont dirig\'{e}s vers la sortie standard (ecran). Dans le cas d'un appel \`{a} partir du shell, le r\'{e}sultat s'affiche \`{a} l'ecran. Dans le cas d'un appel \`{a} partir d'un noyau graphique, il faut pouvoir rediriger les r\'{e}sultats vers le noyau sans modifier la fonction. Cette redirection est mise en place en cr\'{e}ant un 'PIPE' de la fonction vers le noyau appelant au moment de la creation du processus. \subsection{Prise en compte des resultats} \hskip 1 cm Les r\'{e}sultats arrivent par le 'PIPE' Unix sous forme de chaines de caract\'{e}res. Ils doivent n\'{e}cessairement \^{e}tre pris en compte par une fonction interne du noyau graphique. Cela ne pose pas de probl\`{e}me tant que les r\'{e}sultats sont des valeurs num\'{e}riques \`{a} afficher telles quelles. Par contre, il en va tout autrement des lors qu'ils s'agit d'interpr\'{e}ter graphiquement ces r\'{e}sultats sous forme de spectre ou de courbe de fit par exemple. Le noyau graphique doit poss\'{e}der un certain nombre de fonctions internes d'in\-ter\-pr\'{e}\-tation graphique des r\'{e}sultats acceptant comme argument les diverses formes de code de retour des fonctions externes. Comme il n'est pas possible de pr\'{e}voir tous les cas a priori, il faut proposer une liste de formats de r\'{e}sultats reconnus par le noyau graphique et associer \`{a} la definition de chaque appel le format idoine. Cette liste de format \'{e}voluera au cours du temps de mani\'{e}re \`{a} prendre en compte de nouvelles fonctions. \subsection{Configuration du noyau graphique au d\'{e}marrage} \hskip 1 cm Toutes les donn\'{e}es d\'{e}crivant les appels aux fonctions externes sont group\'{e}es dans un fichier ASCII li\'{e} \`{a} la bibliotheque concern\`{e}e. Au d\'{e}marrage, le noyau graphique lit ce fichier, rempli les menus avec les fonctions declar\'{e}es, cr\'{e}e les boites de dialogue correspondantes et positionne les drapeaux de s\'{e}l\'{e}ction des fonction d'interpretation des resultats. \section{Listes des fonctions d'analyse} Une liste de fonctions a \'{e}t\'{e} \'{e}tablie dans EDOC112. Nous examinerons \'{e}galement toutes les fonctions du NSF de Daresbury. Notre objectif est de permettre \`{a} tout physicien de modifier ou de rajouter une fonction en ayant \`{a} changer le moins de choses possibles, notamment dans l'int\'{e}gration dans les menus d\'{e}roulants et de la modification au niveau du dialogue pour l'entr\'{e}e de donn\'{e}es. \section{Outils \`{a} notre disposition} Nous avons etudi\'{e} la documentation de SUN notamment le DEV Guide pour pouvoir en d\'{e}gager les facilites, les possibilites, et en appr\'{e}cier mieux les limites et les adaptations \`{a} faire pour le developpement de notre produit. Ce produit Dev Guide nous a d\'{e}j\`{a} permis de g\'{e}n\'{e}rer le proto de l'\'{e}cran d'analyse ( voir edoc112) d'une fa\c{c}on interactive sans programmation. Nous avons aussi d\'{e}j\`{a} \'{e}labor\'{e} une m\'{e}thode pour utiliser des boites de dialogue , en \'{e}tant le plus independant possible des programmes d'analyse actuels qui devront etre reutilis\'{e}s. Dans une deuxi\`{e}me phase , nous allons etudi\'{e} une proc\'{e}dure permettant \`{a} l'utilisateur de rajouter des options aux menus d'analyse. \section{Echelonnement des travaux} Cette premi\`{e}re approche est \`{a} discuter pour permettre de d'{e}gager tout ce qu'il est possible de d\'{e}velopper et tester s\'{e}paremment . Le test de l'ensemble pouvant se faire ulterieurement . \section{Conclusions} Cet article fait donc un survol de l'architecture des diff\'{e}rents logiciels utilisant un interface graphique. Notre objectif est de disposer d'un document pour l'acquisition (edoc111), le setup (en cours d'\'{e}laboration), le test de carte (en cours d'\'{e}laboration, le controle (en cours d'\'{e}laboration) et l'analyse de spectres(edoc112). \newpage \begin{center} \bf Bibliographie \rm \end{center} Les documents concernant le graphique sont disponibles sur l'info-server Auteurs : L.Michel \& G.Zehnacker \begin{itemize} \item EDOC110 : Developpement graphique - pr\'{e}sentation g\'{e}n\'{e}rale \item EDOC111 : Graphics developpements - Acquisition Spectra and events \item EDOC112 : Developpement graphique - Analysis Functions \& Ergonomics \item EDOC116 : Devguide: a graphical interface editor \item Edoc1xx : Principles and architecture \item Edoc1xx : Display modules - analysis modules \item Edoc1xx : Setup (en cours) \item Edoc1xx : Test (en cours) \item Edoc1xx : Controle (en cours) \end{itemize} \newpage \begin{center} \bf Appendix \ \appendix \vskip 0.3cm Les concepts de base sous X-Window \end{center} Chaque terminal est dot\'{e} d'un clavier, d'un dispositif de pointage et d'un ou plusieurs \'{e}crans. La gestion de ce materiel est assuree par le Serveur X\_Window. L'application graphique est client du serveur X. \section{Communication client serveur} Le protocole est bas\'{e} sur le mod\`{e}le client serveur X developp\'{e} au MIT pour les interfaces graphiques modernes. Dans ce mod\`{e}le les \'{e}changes entre client et serveur X se font par requ\^{e}tes et X events. Le ou les clients envoient toutes les informations necessaires au serveur X pour executer des actions \'{a} l'\'{e}cran . Le graphisme est impos\'{e} par le client. Le serveur X \`{a} son tour renverra une reponse suivant le type de requete du client. Le client et le server ne sont pas executes obligatoirement sur la m\^{e}me machine. Notons aussi que plusieurs clients peuvent interagir avec un serveur X . De la m\^{e}me fa\c{c}on un client peut communiquer avec plusieurs serveurs. \section{La fen\^e{t}re } L'objet de base avec lequel travaille le serveur est la fenetre. Une fenetre est simplement une zone rectangulaire de l'\'{e}cran \`{a} laquelle est associ\'{e} une application. La fenetre associ\'{e}e au serveur lui m\^{e}me est l'\'{e}cran dans sa totalit\'{e}. C'est la fenetre racine. La fen\^{e}tre active est normalement celle dans laquelle se trouvait le pointeur de la souris au moment ou l'evenement s'est produit. Chaque client poss\`{e}de au moins une fen\^{e}tre, pas forc\'{e}ment visible, qui lui est directement associ\'{e}. \section{Les \'{e}v\'{e}nements} L'\'{e}v\'{e}nements traduit une action d\'{e}tect\'{e}e par le serveur concernant un client telle une pression sur un bouton de la souris, une action sur le clavier ou encore une modification de l'emplilement des fenetres. Une caract\'{e}ristique de X-Window est le traitement asynchrone des \'{e}v\'{e}nements. Tous les \'{e}v\'{e}nements seront empil\'{e}s par le serveur et transmis au client. L'evenement est enregistr\'{e} par le client sous forme d'une structure C dont le contenu depend du type d'evenement. Un evenement pour un client peut \^{e}tre de differentes formes , par ex : \begin{itemize} \item la position du curseur au moment du clic, \item la transmission d'un caractere ASCII frapp\'{e} au clavier \item la demande de changement de taille d'une fen\^{e}tre \item la mise en avant ou en arrierre d'une fen\^{e}tre \end{itemize} \section{Le client} Au d\'{e}part le client doit cr\'{e}\'{e}r une ou plusieurs fen\^{e}tres de mani\'{e}re \`{a} disposer d'un espace d'affichage et \`{a} \^{e}tre identifiable par le serveur. Puis le client est mis en sommeil dans l'attente d'evenement. L'arriv\'{e}e d'un evenement g\'{e}n\`{e}re une interruption qui reveille le client ( fonction XNextEvent de la X-Lib ) et executera la fonction correspondante \`{a} ce type d'evenement. \end{document}