TP XWindow / Motif 1

Module EO / Dominante INF
Eric Lecolinet @ ENST

TP1 TP2 TP3 Java Elc Exemples

Mode d'Emploi

Créér un nouveau répertoire et y copier les fichiers se trouvant dans le répertoire: ~domeo/TP-Motif/Motif1
Faites les exercices qui suivent dans l'ordre car ils dépendent les uns des autres. Dans certains cas vous aurez juste à regarder le programme et ce qu'il fait. Dans d'autres cas il sera nécessaire de le compléter.
compilez les programmes au fur et à mesure des exercices. Pour compiler un fichier, vous devrez utiliser la commande make. Par exemple, pour compiler le programme xxx à partir du fichier xxx.c, tapez la commande : make xxx

Attention : la commande make depend du fichier Makefile situé dans le répertoire courant. Ce fichier definit les options de compilation et les librairies adéquates pour générer un programme Motif sous un système d'exploitation donné. Le Makefile courant est conçu pour produire des exécutables sous SunOS5 (alias Solaris2).

Remarques:

La commande uname -a indique le système d'exploitation de la machine utilisée.
Exemple de réponse: "SunOS messiaen 5.4 generic sun4c sparc" ==> SunOS5.
les programmes X-Window / Motif utilisent des librairies dynamiques (i.e. des librairies qui sont chargées au moment de l'exécution du programme). Ces librairies doivent correspondre à celles qui sont indiquées dans le Makefile. En cas de problème, l'ordre de recherche des librairies dynamiques peut être changé en modifiant la variable d'environnement LD_LIBRARY_PATH du Shell Unix.

Afficher un message au moyen d'un Label

Regarder le fichier label.c. On remarquera qu'il y a création de 3 widgets :

toplevel, le widget de plus haut niveau de l'application (toplevel est créé en même temps que le toolkit est initialisé)
box, le "conteneur" ou "Manager" de widgets
message, le Label widget qui sert à afficher un message

Noter que box et message sont "managés". (il faut "manager" les widgets les rendre actifs et les faire apparaître a l'écran).

Un fois les widgets crées, ils sont réalisés physiquement (par XtRealizeWidget) puis l'application entre dans la boucle infinie de gestion des événements.

Compiler et exécuter le programme "label". Quel est le message affiché ?

Attention : ne pas confondre les VARIABLES C qui pointent sur les widgets (valeur renvoyée par les fonctions XmCreateXXX) avec le NOMS des widgets (2eme argument des fonctions XmCreateXXX). Les premiers sont des pointeurs alors que les second sont des chaînes de caractères servant à désigner les widgets dans les Fichiers de Ressources.

Ajouter un PushButton

Compléter le fichier pushbutton.c comme suit :

Créer (et manager) un nouveau widget :
- de classe XmPushButton,
- de nom button,
- ayant pour père le widget box.
Lier la fonction Sortir (déjà définie dans le code source) au bouton que l'on vient de créer de telle sorte que cette fonction soit appelée quand on clique sur le bouton.
Utiliser la fonction XtAddCallback (faire "man XtAddCallback") avec XmNactivateCallback en guise de "callback_name"
Note : XmNactivateCallback ==> fonctions de callback appelées quand on "active" le bouton, c'est-à-dire quand on clique dessus avec le bouton 1 de la souris ou que l'on frappe la touche SPACE lorsque le widget "a le focus".
Compléter la fonction Sortir de telle sorte :
- qu'elle affiche un message d'adieu (en utilisant printf),
- puis qu'elle termine l'application.
Compiler et exécuter le programme pushbutton.

Fichiers de Ressources

Les fichiers de ressources permettent de spécifier la valeur des ressources des widgets sans modifier le code C. Les spécifications sont de la forme :


    appli.widget1.widget2. .... widgetN.ressource : valeur

Avec :

appli = nom ou classe de l'application
widget1 ... widgetN = widgets traversés dans l'arborescence pour aller de widget1 (le plus "haut") à widgetN (le plus "bas" = celui dont on veut changer les ressources)
widget1, etc ... sont les NOMS des widgets (c'est-à-dire le 2eme argument des fonctions XmCreateXXX)
ressource = nom de la ressource de widgetN à modifier
valeur = sa nouvelle valeur (dépend du type de ressource)

De plus : * = joker qui évite de préciser les widgets intermédiaires.

Exemples :


  *box.message.labelString : Hello New World
  *button.labelString : Click and Die!

! les lignes commençant par ! sont des commentaires
! sur une station couleur seulement (sinon se limiter aux "couleurs" white et black) :


  *background : red
  *box*foreground : blue
  *message.background : green
  *XmPushButton.background : pink

Remarque : Comme le montre la dernière ligne, on peut également spécifier des classes de widgets. On peut ainsi modifier globalement tous les objets d'une même classe, sans avoir à les spécifier individuellement.
Noter que les noms des classes commencent généralement par une majuscule et ceux des instances par une minuscule.

Exercice :

Créer un fichier de ressources pour les programmes label et pushbutton en vous inspirant des exemples précédents. Ce fichier devra obligatoirement :

se trouver soit dans votre "home directory", soit dans le répertoire courant suivant l'installation.
avoir pour nom XMdemos. Ce nom est celui de la classe des applications "label" et "pushbutton" et correspond au 2eme argument de la fonction XtAppInitialize.

Relancer les programmes label et pushbutton après création du fichier de ressources. Essayer diverses variantes (sans oublier de relancer les programmes après chaque modification du fichier de ressources).

Comment faire pour que les ressources des widgets des programmes label et pushbutton aient des valeurs différentes ?

Remarques :

un même fichier de ressource peut agir sur plusieurs applications si elles sont de même classe (on rappelle: classe de l'appli. = nom du fichier de ressources = 2eme argument de XtAppInitialize)
les applications ne sont pas nécessairement situées dans les mêmes répertoires que les fichiers de ressources. Ces derniers doivent se trouver dans les repertoires définis par les variables d'environnement $XAPPLRESDIR ou $XUSERFILESEARCHPATH (-> commande echo pour visualiser ces variables).
le répertoire /usr/lib/X11/app-defaults contient un ensemble de fichiers de ressources prédéfinis qui sont communs à tous les utilisateurs,
au lancement d'une application, X lit d'abord les ressources "système" (i.e. dans /usr/lib/X11/app-defaults) puis les ressources "utilisateur" (cf. precedemment) en "écrasant" les définitions qui existent déjà. Pour une fois c'est donc l'utilisateur qui a le dernier mot !

Fichier .Xdefaults

Le fichier .Xdefaults permet également d'initialiser des ressources. Contrairement au cas précédent, ce fichier est commun à toutes les applications quelle que soit leur classe.

Le principe est le même que précédemment sauf que :

Ce fichier n'est chargé qu'une fois, au lancement de Xwindow. Il faut recharger ce fichier après modification pour que les nouvelles définitions soient prises en compte. Pour ce faire, exécuter la commande : xrdb -load ~/.Xdefaults
il faut préfixer les définitions par le nom de l'application ou de sa classe (sinon les définitions s'appliquent à TOUTES les applications !),

Exemples :


  XMdemos*message.labelString : Message defini dans .Xdefaults
  pushbutton*message.labelString : Message juste pour l'application "xmbutton"
  pushbutton*button.labelString : Adieu \n Monde \n Cruel...

Remarques :

le fichier .Xdefaults est situé dans le "home directory",

les definitions dans .Xdefaults sont prépondérantes sur celles des fichiers de ressources,

les lignes commençant par des ! sont des commentaires.

Listes d'Arguments

Les listes d'arguments (ou ArgLists) permettent d'initialiser ou de modifier les valeurs des ressources dans le fichier C. Leur utilisation est plus complexe (que celle des fichiers de ressource) car les valeurs des ressources doivent alors être explicitement converties en un type adéquat (Par exemple, les chaînes de caractères C doivent être converties en chaînes de caractères Motif (de type XmString), les noms de couleurs doivent être convertis en valeurs de type Pixel, etc ...)

Le programme arglist.c montre comment initialiser les ressources du Label message pour lui faire afficher un texte en noir sur fond blanc. Noter que :

la définition des ressources se fait avant la création du widget concerné
la liste d'arguments args est un tableau de couples (nom-de-resource, valeur-de-resource) que l'on initialise au moyen de la MACRO XtSetArg
le 3ème argument des fonction XmCreateXXX doit être la liste d'arguments (ou NULL s'il n'y en n'a pas),
le 4eme argument doit être le cardinal de cette liste (i.e. le nombre de couples ressources/valeurs effectivement définis),
les noms des ressources commencent toujours par XmN suivi d'une lettre minuscule,
ces ressources sont désormais fixées, elles ne pouront être modifiées que dans le code C (les définitions des fichiers de ressources seront sans effet sur ces ressources).

Attention

ne pas préfixer les noms des ressources par XmN dans les fichiers de ressources. Ce prefixe est seulement nécessaire dans le code C.
attention aux minuscules et aux majuscules !
ne pas se tromper de cardinal, ne pas mettre " n++ " comme argument de la macro XtSetArgs, prévoir un tableau suffisamment grand, etc ...

Remarque : Noter l'utilisation de la fonction XmStringCreateLocalized pour transformer des chaînes de caractères normales en chaînes de caractères Motif (de type XmString). On aurait également pu utiliser les fonctions XmStringCreate ou XmStringCreateLtoR qui ont des fonctionnalités légèrement différentes (ces fonctions permettent de créer des chaînes Motif mélangeant plusieurs polices de caractères). Enfin, la fonction XmStringFree permet de récupérer la place mémoire allouée à la chaîne Motif quand on n'en a plus besoin.

Compilez et exécutez arglist.c.

Modification dynamique des valeurs des ressources

Les étapes précédentes ont montré comment spécifier les valeurs des ressources :

via un fichier de ressources ou le fichier .Xdefaults
dans le code C avant création des widgets.

Dans les deux cas les ressources sont définies à l'initialisation, c'est-à-dire de manière "statique". Cet exercice propose de les modifier de manière dynamique, c'est-à-dire en cours d'exécution du programme.

Le programme dynarg.c crée 3 widgets : un Label pour afficher un message, un bouton pour terminer l'application et un troisième bouton qui aura pour fonction de faire alterner les couleurs du "foreground" et du "background" du Label.

Comme précédemment, le texte du Label est affiché en noir sur fond blanc, mais ceci est réalisé d'une manière différente : le Label est d'abord crée puis ses resources sont modifiées dynamiquement au moyen de la fonction XtVaSetValues. On remarque que :

le 1er argument de XtVaSetValues est le widget sur lequel la modification s'applique
le dernier argument doit toujours être NULL
les arguments intermediaires constituent des couples (nom-de-ressource, valeur)
le nombre de couples (nom, valeur) est variable
cette fonction a entre-autres l'avantage d'éviter d'avoir à créer explicitement des tableaux d'arguments comme dans l'exercice précédent

Remarques

Certaines ressources ne peuvent pas être modifiées une fois le widget crée

La fonction XtVaGetValues remplit le role inverse de XtVaSetValues: elle permet de récupérer la valeur courante d'une ressource d'un widget.
! Attention : cette fonction suppose de connaître le type C exact des ressources à récupérer. Le type des ressources est indiqué dans le manuel des classes de widgets Motif.

Pour avoir des informations sur une ressource donnée (type C, possibilité de modification, explications ...) il faut consulter le manuel (via les commandes man ou xman) du WIDGET auquel cette ressource appartient (par exemple, pour avoir des infos. sur la ressource XmNbackground d'un PushButton, consulter le manuel de XmPushButton).

Exercices
En vous inspirant de ce qui précède, rajoutez une fonction de callback qui alterne les couleurs du Bouton xchange quand on clique dessus (ie. qui échange les valeurs de son foreground et de son background)
Encore plus fort ! : faire la même chose mais en échangeant cette fois les couleurs du Label message et sans utiliser de variable globale (aide : regarder le manuel de la fonction XtAddCallback ou ... le cours).

Geometry Managers et Orientation

Cet exemple montre comment modifier les ressources d'un Geometry Manager de classe RowColumn afin de disposer verticalement, horizontalement ou matriciellement les widgets qu'il contient.
Le programme orientation.c crée un Label et 5 PushButtons.

quit termine l'exécution de l'application
horizontal dispose les widgets horizontalement
vertical dispose les widgets verticalement
lineaire dispose les widgets linéairement
matricel dispose les widgets matriciellement.

Les 4 derniers boutons appellent des fonctions de callback qui changent dynamiquement certaines ressources du widget box, lequel est un manager de type RowColumn.

Compiler et exécuter le programme. Essayer les 4 possibilités : horizontal+linéaire, vertical+linéaire, horizontal+matriciel, vertical+matriciel.

Changer la taille de la fenêtre à l'aide de la souris dans chacun des 4 cas. que constate-t'on ?

Examiner le code. On voit que :

pour simplifier l'écriture, on a défini une fonction utilitaire (CreateButton) qui cree un PushButton et lui associe une fonction de callback
le dernier argument de cette fonction (le widget box) sera automatiquement passé à la fonction de callback lorsque celle-ci sera appelée. Cette technique évite d'avoir a utiliser des variables globales
les enfants du RowColumn box sont managé globalement au moyen de la fonction XtManageChildren

Ajout dynamique de widgets et changements de taille

Cet exemple montre :

comment rajouter ou détruire dynamiquement des widgets (c'est-à-dire après la phase d'initialisation)
comment spécifier ou modifier une police de caractère (ou une couleur) de manière astucieuse
comment créer des ToggleButtons (boutons d'état) exclusifs
comment le Manager RowColumn réagit quand on modifie par programme la taille d'un de ses enfants ou que l'on rajoute de nouveaux enfants.

Compilez et exécutez le programme addobj. Celui-ci comprend initialement:

une zone de message
deux ToggleButtons exclusifs affichés avec des fontes (i.e. polices) différentes
un bouton add
un bouton quit

Cliquez sur les boutons small et big. Que se passe-t'il ? Changez la taille de la fenêtre à l'aide de la souris puis faites de même que précédemment. Que constatez-vous ? Cliquez maintenant sur le bouton add plusieurs fois. Même chose sur remove.
Examinez le code source à partir de la fonction main en faisant attention aux points suivants :

main commence par une definition de fallbacks. Les fallbacks permettent de spécifier les ressources à la manière des Fichiers de Ressources externes. Ces dénitions servent de "dernier recours" (i.e. elles seront écrasées par d'éventuelles spécifications externes). Noter que la variable fallbacks est un tableau de chaînes de caractères et que c'est le 7e argument de XtVaAppInitialize.
l'interface contient deux Managers emboîtes: bigform (qui est un RowColumn) et radiobox (qui est une variante de RowColumn). radiobox est fils de bigform et sert uniquement à contenir les deux boutons d'état exclusifs. Il est courant d'emboîter des Managers pour obtenir une présentation ou une fonctionnalité adéquate (dans le cas présent c'est parce qu'ils sont fils d'un RadioBox que les deux boutons d'état sont exclusifs).
On a défini plusieurs "fonctions utilitaires" pour simplifier l'expression. Ces fonctions pourront eventuellement être réutilisées dans d'autres programmmes. Les fonctions CreatePushButton et CreateToggleButton servent à créer des boutons standard, les manager, et leur rajouter une fonction de callback. Les fonctions de callback DestroyCB et ExitCB servent respectivement à détruire un widget et à sortir de l'application.
une astuce est utilisée pour échanger la fonte de la zone de message : la fonction ChangeFontCB récupère la fonte du ToggleButton qui l'appelle puis l'affecte au message. Cette technique est plus commode et plus générale que ce que l'on avait fait dans dynarg.c pour échanger les couleurs (d'autant plus qu'elle permet de définir les valeurs souhaitées dans des fallbacks ou dans un fichier de ressources).
la création dynamique du nouveau bouton se fait dans la fonction de callback AddButtonCB de manière similaire à ce qui est fait dans la fonction main. Le bouton nouvellement créé sera automatiquement mis à la suite des enfants déjà existants par le RowColumn (c'est une propriété importante de ce type de Manager).

Boîtes de Dialogue

Un MessageDialog sert à afficher un message important tel que : message d'erreur, question, avertissement, information, etc ... Ce type de boîte de dialogue comprend :

un symbole graphique sous forme de pixmap
une zone de message,
trois boutons nommés OK, Cancel et Help.

Les MessageDialogs sont crées au moyen des fonctions Motif XmCreateXXXDialog avec XXX = Message, Error, Information, Question, Warning et Working. Toutes ces fonctions créent des boîtes de dialogue identiques au pixmap près. Dans tous les cas l'objet crée est un Manager particulier de classe XmMessageBox (voir manuel Motif).
Les principales ressources des MessageDialogs sont:

XmNdialogTitle : titre du Dialogue
XmNmessageString et XmNsymbolPixmap : message et pixmap affichés
XmNokLabelString, XmNcancelLabelString et XmNhelpLabelString :
labels (i.e. texte) des boutons OK, Cancel et Help
XmNokCallback, XmNcancelCallback et XmNhelpCallback :
fonctions de callback associées aux boutons OK, Cancel et Help
XmNautoUmanage : si cette ressource vaut True (le défaut), le Dialogue disparaitra automatiquement quand on cliquera sur les boutons OK ou Cancel
XmNdialogStyle : décide si le dialogue est modal (= bloquant)

De même que précédemment, les valeurs des ressources XmNxxxString sont des XmStrings (i.e. des chaînes de caractères Motif) qui sont créées au moyen des fonctions XmStringCreate... (et que l'on peut avantageusement spécifier dans les fallbacks (voir exercice précédent) ou dans les fichiers de ressources).
Les callbacks s'ajoutent aux boutons OK, Cancel et Help de la même façon que précédemment (c'est-à-dire à l'aide de la fonction XtAddCallback mais avec les "callback_names" adéquats).
Les boîtes de dialogues sont géneralement des objets éphémères ("transient" en anglais) qui n'apparaissent à l'écran que de manière temporaire (par exemple pour signaler une erreur, demander confirmation d'une commande, etc ...). Pour faire apparaître un Dialog, on utilise la fonction XtManageChild (comme pour les autres widgets). Inversement, la fonction XtUnmanageChild permet de faire disparaître un Dialogue. La ressource XmNautoUmanage entraine une disparition implicite quand on clique sur les boutons OK ou Cancel du dialogue.
Exemple : Compilez et exécutez le programme dialog.c. On remarquera :

que l'on peut encore cliquer sur les touches de la fenêtre principale lorsque le dialogue est ouvert (le dialogue n'est pas modal)
que le bouton open permet non seulement d'ouvrir le dialogue mais aussi de le faire revenir au premier plan lorsqu'il est recouvert par une autre fenêtre

Ce programme utilise les mêmes "fonctions utiles" que l'exemple précédent. La boîte de dialogue est créée une seule fois en même temps que les autres widgets et n'est jamais détruite. Elle est initialement invisible (i.e. pas managée) et n'apparaît que lorsque l'on clique sur le bouton open. Ce bouton appelle la fonction de callback OpenDialogCB, une nouvelle "fonction utile" que l'on pourra réutiliser ailleurs.
Exercice :
Rajouter un QuestionDialog demandant à l'utilisateur de confirmer lorsque l'on clique sur le bouton quit (i.e. cliquer sur quit ouvrira ce dialogue de confirmation (au lieu de sortir directement) et il faudra alors cliquer sur le bouton "OK" de ce dialogue pour terminer l'application).
Remarque: il faudra utiliser 2 fonctions de callback, l'une pour ouvrir le QuestionDialog et l'autre pour terminer l'application.

Récuperer des données depuis une boîte de Dialogue

Un PromptDialog est similaire à un MessageDialog sauf qu'il permet à l'utilisateur d'entrer une donnée tapée au clavier.
un SelectionDialog fait de même mais permet également de sélectionner une donnée dans une liste.
un FileSelectionDialog sert à sélectionner un fichier dans un répertoire (ce dialogue prédéfini est particulièrement utile !).

L'objet crée est un Manager particulier de classe XmSelectionBox dans les deux premiers cas et XmFileSelectionBox dans le dernier cas. Ces dialogues n'ont pas de ressources XmNmessageString ni XmNsymbolPixmap. Les PromptDialogs ont par contre les ressources suivantes:

XmNtextString : texte entré par l'utilisateur (sous forme de XmString)
XmNselectionLabelString : message affiché au dessus de la zone de texte
Pour les autres ressources, voir le manuel le Motif de ces classes.
Exemple : Compilez et exécutez le programme promptdialog. Ce programme montre comment récupérer une chaîne de caractères depuis un PromptDialog.
Regardez comment la fonction de callback GetAndSetTextCB récupère le texte tapé par l'utilisateur. Le 3eme argument (ou "call_data") de cette fonction pointe vers une structure dépendante du PromptDialog (c'est-à-dire du widget qui a appelé cette fonction). Cette structure comprend entre-autres un champ value qui contient le texte entré par l'utilisateur (pour savoir ce que contient cette structure, voir manuel de XmSelectionBox). Comme d'habitude, ce texte est stocké sous forme de XmString qu'il faut éventuellement convertir en String standard au moyen de la fonction XmStringGetLtoR,
Remarques:

on pourrait également faire un XtVaGetValues sur la ressource XmNtextString pour récuperer le texte entré.
le texte tapée dans le dialogue ne s'efface pas quand on ferme la boîte de dialogue et qu'on la rouvre ensuite: il y a "persistance" des données.

Modalité et Fonctions Utiles

Le programme modaldialog.c est semblable au précédent sauf que:

il utilise un certain nombre de "fonctions utilitaires" simplifiées que l'on pourra éventuellement utiliser par la suite pour rendre les programmes plus concis et plus lisibles,
ce programme gère explicitement la modalité des boîtes de dialogue: en essayant ce programme, on remarquera :

que le dialogue de confirmation de sortie est modal (c'est-à-dire bloquant) mais pas celui qui sert à entrer les données
que le dialogue d'entrée des données reste présent quand on clique sur OK (mais pas quand on clique sur Cancel)

Examinez le code source:

En plus des fonctions déjà définies dans addobj.c ce programme comprend la fonction CreateAnyDialog (et des variantes du type CreateXxxDialog) qui sert a créer une boîte de dialogue et à attacher une fonction de callback au bouton OK. L'argument modal_dialog indique si le dialog doit être modal. Si l'argument auto_unmanage vaut True, le dialogue disparaitra quand on clique sur OK ou Cancel, sinon il ne disparaitra QUE si l'on clique sur Cancel.
L'utilisation de la fonction GetDialogChild montre comment enlever le bouton Help (ou d'autres widgets) des boites de dialogue prédéfinies.
Noter que certains widgets sont crées à l'aide de la fonction XtVaCreateManagedWidget. Cette forme est équivalente à : XmCreateXXX + XtManageChild. Elle permet de plus de spécifier de spécifier des couples (ressource, valeur) à la manière de XtVaSetValues.
Attention : cette fonction ne peut pas être utilisée dans tous les cas. On est par exemple obligé d'utiliser la fonction XmCreatePromptDialog pour créer un PromptDialog car ce widget n'est pas une classe à part entière mais une variante de la classe XmSelectionBox.

Exercices :

Rajouter un bouton qui ouvre un FileSelectionDialog. Le bouton OK du FileSelectionDialog devra lancer la lecture du fichier selectionné par l'utilisateur. Si ce fichier existe, il faudra en afficher le contenu sur le Label message, sinon, il faudra ouvrir un dialogue d'alerte modal pour signaler l'erreur à l'utilisateur.
Remarques :
- utiliser la fonction XmStringCreateLtoR pour transformer les chaînes de caractères C en XmString Motif. Cette fonction interprète les \n comme des passage à la ligne contrairement à XmStringCreateLocalized.
- on pourra se contenter d'afficher la première ligne du fichier sur le Label message.
positionner interactivement le PromptDialog lorsque l'on tape un couple de coordonnées (i.e. x puis y séparés par des blancs) dans le champ texte du PromptDialog.
Remarque : modifier dynamiquement les ressources XmNx, XmNy et XmNdefaultPosition du PromptDialog. Noter que XmNdefaultPosition doit valoir False sinon le dialog est positionné automatiquement par le Window Manager sans tenir compte des valeurs de XmNx et de XmNy.

Autres Dialogues Prédéfinis
- un CommandDialog sert à taper une commande qui est conservée dans une historique.
- un TemplateDialog est un MessageDialog vide (à part les 3 boutons OK, Cancel et Help), servant de base à la création de dialogues complexes
- un FormDialog (resp. BulletinBoardDialog) est une boîte de dialogue entièrement vide comprenant uniquement un Form (resp. BulletinBoard) Manager. Ces boîtes de dialogues servent à créer des fenêtres secondaires complexes.
Annexe A: Afficher un pixmap
Regarder le fichier pixmap.c. On remarquera qu'il y a création de 3 widgets :
- toplevel, le widget de plus haut niveau de l'application (toplevel est créé en même temps que le toolkit est initialisé)
- box, le "conteneur" ou "Manager" de widgets
- label1, le Label widget qui servira à afficher un pixmap
Ceci s'apparente au programme "label.c".
Cependant on crée maintenant un Pixmap qui peut être vu comme un masque de points. Il y a différentes façons de créer un Pixmap, nous utilisons ici la fonction XmGetPixmap qui prends en argument un nom de fichier au format xbm (format bitmap) , ainsi que les couleurs d'avant et d'arrière-plan du dessin.
Les fichiers au format xbm peuvent être créés par le programme bitmap
Compiler et exécuter le programme "pixmap".

Elc: Cours & Exemples

Page maintenue par Eric Lecolinet (elc@enst.fr). Sept 95 / Apr 97.

TP XWindow / Motif 1

Module EO / Dominante INF Eric Lecolinet @ ENST

Mode d'Emploi

Afficher un message au moyen d'un Label

Ajouter un PushButton

Fichiers de Ressources

Fichier .Xdefaults

Listes d'Arguments

Modification dynamique des valeurs des ressources

Geometry Managers et Orientation

Ajout dynamique de widgets et changements de taille

Boîtes de Dialogue

Récuperer des données depuis une boîte de Dialogue

Modalité et Fonctions Utiles

Autres Dialogues Prédéfinis

Annexe A: Afficher un pixmap

Module EO / Dominante INF
Eric Lecolinet @ ENST