La gestion de l’interface graphique

Au cours d’une activité, l’atelier manipule les interfaces graphiques de différents prototypes. Toutes ces interfaces graphiques ne sont pas utiles pendant tout le temps de l’activité. Notre but est d’afficher sur un écran unique (l’écran hôte sur lequel l’activité a lieu) toutes les fenêtres (ou une parties des fenêtres) issues des différents prototypes. C’est, par exemple, ce que permet un terminal X (appelé TX). TX est une station de travail où des logiciels Unix tournant sur un serveur peuvent être utilisés. Les éléments graphiques nécessaires à l’utilisateur pour interagir avec le logiciel sont affichés sur l’écran du TX. Notre but est d’utiliser ce type de terminal sur la machine hôte du prescripteur, pour gérer les différentes interfaces graphiques produites par les différents prototypes. Cette gestion nécessite de sélectionner ce qui doit être présenté à l’écran et d’organiser l’écran de manière à minimiser la charge cognitive nécessaire à l’utilisateur pour suivre l’activité. Cependant ce type d’interface graphique virtuelle n’existe pas encore. De plus, elle nécessite un travail de recherche conséquent, qui dépasse le cadre de ce travail.

Pour résoudre notre problème, nous utilisons un gestionnaire d’interfaces graphiques qui per- met de définir une fenêtre55 _{englobant les interfaces graphiques que nous importons des pro-}

totypes. Pour les inclure dans notre fenêtre englobante, nous avons besoin de composants qui exportent leur interface graphique. C’est pour cela que nous avons défini une propriété des in- terfaces graphiques : elles doivent être interface-exportable (section 1.2.3). Dans ce cas, nous affichons l’interface graphique du composant sur l’écran du sujet de l’activité. Ainsi, le sujet peut agir directement sur son écran comme s’il était sur le logiciel distant.

Rappelons que cette propriété est une forme de paramétrisation de l’interface graphique : elle permet par exemple de lancer l’interface graphique à l’endroit désiré. Dans le cas où nous avons un prototype ayant cette propriété, nous utilisons un composant de services pour gérer l’interface graphique du prototype au sein d’une activité. Ce composant de services est appelé gestionnaire d’interfaces graphiques (voir section 4.7.1). Notre but était de spécifier notre besoin, étant donné que nous ne possédions pas de prototypes ayant cette propriété. Pour cela, nous avons utilisé des solutionsad ho afin de tester notre atelier avec les prototypes existants (voir section 4.7.2). Ces

solutions utilisent la spécification du gestionnaire d’interfaces graphiques. Cela nous permet de changer la solution adopté en modifiant le moins possible le reste de l’atelier.

4.7.1 Le gestionnaire d’interface graphique

Le gestionnaire d’interface graphique est un composant de services permettant de gérer les interfaces des différents prototypes lancés. Nous considérons ici les prototypes ayant la bonne pro- priété «interface graphique exportable». Puisque les prototypes peuvent exporter leur interface graphique, le gestionnaire d’interfaces graphiques les importe. Il doit alors pouvoir les position- ner dans l’espace de l’écran et dans le temps de l’activité. Nous avons par conséquent défini les fonctionnalités du gestionnaire d’interfaces graphiques en fonction de la vitrine dont nous avions besoin. La vitrine du gestionnaire d’interfaces graphiques est donnée ci-après :

AffectIDWindow() CreateIncludingWindow() ActivateWindow() DesactivateWindow() OrganizeWindow() 55

4.7. La gestion de l'interfa e graphique 133

L’interface graphique d’un prototype étant incluse dans une fenêtre, nous donnons à cette fenêtre un identificateur grâce à la méthode AffectIDWindow(). Ensuite nous pouvons insérer cette in- terface graphique dans une fenêtre qui l’inclut : cette fenêtre est celle qui est positionnée à l’écran du poste où se déroule l’activité. Ceci se fait par la méthode CreateIncludingWindow(). Ceci fait, il est possible d’activer, de désactiver et de positionner la fenêtre en fonction des besoins de l’activité grâce aux méthodes ActivateWindow(), DesactivateWindow() et OrganizeWindow().

4.7.2 Solutions ad hoc

N’ayant pas de prototypes ayant les propriétés adéquates, nous avons recherché une solution

adho dans deux cas. Le premier cas est celui de l’expérimentation deTALC etMentoniezh. Le

second cas est celui de l’expérimentation des autres prototypes dont nous disposions. La dernière solution est la plus générale.

Première solution

Le premier besoin de gérer les interfaces graphiques est apparu lorsque nous avons voulu faire coopérerTALC etMentoniezh tournant sur Macintosh. A l’époque les notions de scénario

d’expérimentation et de médiateur n’avaient pas encore été conçues. Notre but étant de montrer la possibilité d’utiliser un interprète de macro-définitions, nous avons choisi d’implanter une première plate-forme sur la même machine (un même Macintosh).TALC etMentoniezh étaient

alors lancés en même temps et la gestion des interfaces graphiques se faisait manuellement. Nous avons ajouté des boites de dialogues pour donner des consignes à l’utilisateur et pour recevoir des messages de l’utilisateur en particulier pour qu’il signale qu’il a fini une étape.

Cette solution est pratique pour le test. Cependant elle n’est pas envisageable lors d’une expérimentation avec des sujets. En effet, trop de fenêtres sont actives en même temps et le sujet ne sait pas celle qu’il doit prendre en compte à un moment donné sans l’aide d’un guide humain. L’affichage de boites de dialogues pour l’yaider n’était pas suffisants. Cette solution a en outre l’inconvénient de restreindre l’usage des prototypes tournant sur la même machine : soit Macintosh, soit PC, soit Unix.

Solution plus générale

Choix d’un logiciel Pour pouvoir utiliser des prototypes tournant sur des machines diffé- rentes, nous avons étudié les logiciels existants, dont VNC [VNC http] et p Anywhere

56_{. Ces}

logiciels permettent de visualiser l’écran d’un ordinateur sur un autre et d’agir indifféremment de l’un ou de l’autre. Pour le p Anywhere, comme son nom l’indique, c’est uniquement l’écran

d’un PC qui est visualisé. En revanche, il offre des fonctionnalités intéressantes, que n’offre pas

VNC, en particulier la possibilité de transférer des données entre le PC recevant l’écran et celui

l’émettant. C’est pourquoi, dans une activité utilisant des prototypes tournant exclusivement sur PC, l’utilisation de p Anywhere est très intéressante. Cependant, nos prototypes peuvent avoir

des systèmes d’exploitations différents. Par conséquent, nous avons utilisé le logicielVNC.

Notre utilisation de VNC L’exemple 4.5 illustre une utilisation possible de VNC.

56 c

134 Chapitre 4. Implantation de l'atelier

Exemple 4.5 Nous lançons d'une part CABRI-Géomètre

a

sur un Ma intosh et nous ongurons e Ma intosh entant que serveur VNC.Nous lançons d'autre part Mento-

niezh sur un PC et nous ongurons e PC en tant que serveur VNC. Le Ma intosh et le PC sont reliés par un réseau

b

à une station Unix. La station Unix est ongurée entant que lient VNC.Nouslançons l'ateliersur la stationUnix. Nouspouvons alors visualiser CABRI-Géomètreet Mentoniezhsurla stationUnixetagirsurl'unetl'autre omme sinous étionssur le PCet sur leMa intosh.

a

Pour présenter le principe de VNC ici, nous ne parlons pas ici des modifications apportées aux prototypes pour fonctionner avec CORBA

b

intranet ou internet

Cette solution a l’inconvénient de mobiliser trois machines dans le cas de l’exemple 4.5. Cependant elle a l’avantage de ne pas nécessiter d’installer sur la station Unix un émulateur PC pour lancer

Mentoniezh et un émulateur Macintosh pour lancer CABRI-Géomètre. L’intérêt de VNC par

rapport à d’autres produits existants à l’époque de l’expérimentation est double. D’une part,

VNC est gratuit. D’autre part, VNC permet toutes les combinaisons possibles : la machine

cliente (qui reçoit les interfaces graphiques) peut être un PC57_{, un Macintosh ou une station}

Unix, tandis que la machine «serveur» peuvent aussi être un PC, un Macintosh ou une station Unix.

Ce paragraphe achève la description de l’implantation de nos composants. Les paragraphes suivant décrivent la mise en œuvre de l’atelier.