Ce chapitre est consacré à la mise en oeuvre des spécifications du placement spatial dans le prototype Madeus.
La section 2 présente le contexte matériel et logiciel du projet. La section 3 décrit la démarche de réalisation suivie. La section 4 présente la mise en oeuvre de ce placement, en particulier sa définition syntaxique et l'intégration modulaire du résolveur de contraintes. Enfin, la section 5 présente les éléments d'interface développés dans le cadre de ce projet.
Le prototype Madeus est développé sur une station de travail Sun UltraSPARC-1, sous le système d'exploitation Solaris 2.5. Une version de Madeus sous le système Linux est en cours de réalisation et un portage dans l'environnement Windows NT est prévu.
Le prototype Madeus est écrit en langage C et comporte certains modules en C++. L'interface graphique est réalisée à partir du système de fenêtrage X Window et de la boîte à outils Motif définie par Open Software Fondation . Les documents Madeus sont traités par l'analyseur lexical Flex et l'analyseur syntaxique Bison.
Motif est une boîte à outils orientée objet qui offre aux utilisateurs des routines leur permettant d'inclure dans leurs programmes les éléments d'interface graphique les plus couramment utilisés. Motif est basé sur l'environnement X Window qui fournit les primitives de base indépendamment de l'environnement matériel et logiciel.
L'environnement X Window utilise le modèle client-serveur et se caractérise par une transparence du réseau, un bon niveau de portabilité et une structure hiérarchique des fenêtres. Il distribue les événements de manière automatique aux objets de dialogue concernés. Un programme client peut manifester son intérêt pour certains événements en leur associant des procédures de traitement appelées callbacks. Ces procédures sont automatiquement exécutées sur l'occurrence de l'événement qui leur est associé, en complément du traitement général des événements.
La Fig 1 décrit les principaux composants de la boîte à outils Motif, en montrant les différents niveaux d'abstraction depuis les services de la Xlib de l'environnement X Window jusqu'aux bibliothèques élaborées de Motif.
Fig 1. L'environnement X Window
Dans l'environnement X Window, les deux classes de services (gestion du poste de travail et gestion du dialogue) sont interfacées dans des bibliothèques distinctes. Cet environnement regroupe les primitives d'accès aux services de base dans la bibliothèque Xlib et les services de dialogue dans la bibliothèque Xt, également appelée intrinsics.
L'élément principal de Motif concerne la boîte à outils d'objets d'interface (Motif Toolkit). Grâce à elle, le programmeur peut paramétrer et combiner ces objets pour créer une interface utilisateur. La boîte à outils est élaborée sur la bibliothèque Xt qui définit des classes de base et un modèle de construction d'objets appelés widgets.
La boîte à outils Motif comprend également un langage de description de l'interface nommé UIL (User Interface Language). Ce langage permet de séparer la description lexicale et syntaxique de l'interface du programme.
Enfin, Motif comprend un générateur de fenêtres appelé Motif Window Manager.
Pour l'analyse des documents Madeus, nous utilisons les outils Flex et Bison développés par l'université de Berkeley. Flex est un analyseur lexical qui transforme une suite de caractères lus en entrée en une suite de mots ou tokens. Bison est un analyseur syntaxique qui lit une suite de tokens délivrés par l'analyse lexicale et les transforme en une séquence d'actions. Le fonctionnement général de ce processus d'analyse est schématisé dans la Fig 2 .
Fig 2. Processus d'analyse des documents Madeus avec les outils Flex et Bison
A partir de la définition de règles lexicales et d'actions associées à celles-ci, Flex génère une fonction yylex() pour l'analyse lexicale. Cette fonction, après compilation, est capable de transformer les expressions régulières contenues à l'intérieur d'une suite de caractères en une suite de tokens et d'exécuter les actions spécifiques à chacune d'elles.
A partir de la définition de règles grammaticales et d'actions associées à celles-ci, Bison génère une fonction yyparse() pour l'analyse syntaxique. Cette fonction, après compilation, lit une séquence de tokens produits par l'analyse lexicale, les regroupe selon les règles définies par la grammaire et, si le groupe correspond à une règle grammaticale, exécute les actions associées à celle-ci.
Le résultat de ce processus est un fichier cohérent avec les règles définies par l'utilisateur et sur lequel certaines actions peuvent être appliquées. Dans Madeus, ce processus consiste à traduire un document textuel dans le format interne de l'application pour pouvoir être ensuite manipulé et modifié.
La réalisation de ce projet s'est déroulée en trois étapes : réalisation d'un prototype de placement statique d'éléments puis, réalisation d'un prototype de placement interactif et enfin, définition d'une spécification de placement spatial dans Madeus et intégration du résolveur de contraintes DeltaBlue. Dans cette section, nous allons présenter les deux premiers prototypes développés.
Le premier prototype réalisé est celui présenté dans la section 0 pour le test des deux résolveurs de contraintes initialement retenus.
L'intérêt principal de ce prototype était d'étudier sur un exemple concret l'utilisation de résolveurs de contraintes dans le cadre d'une interface graphique. Nous avons ainsi mieux appréhendé leurs principes de fonctionnement et leurs possibilités d'évolution, notamment pour ce qui concerne la définition de nouvelles contraintes. Nous avons également pu constater leurs avantages par rapport à nos objectifs, comme leur relative facilité d'utilisation, l'aspect déclaratif de la spécification des contraintes et la prise en compte immédiate des perturbations du système. Nous avons également constaté leurs limitations concernant la gestion des cycles et des contraintes d'inégalité.
Un autre intérêt de ce prototype a été de définir le mécanisme de transformation des relations spatiales exprimées entre des éléments en contraintes sur les variables de ces éléments.
Enfin, ce prototype a permis de mettre en relief un des problèmes liés à l'utilisation des contraintes pour spécifier un comportement à savoir celui de leur visualisation.
Le second prototype réalisé permet le placement interactif d'éléments par ajouts et retraits successifs de relations. C'est un prototype proche de Madeus dans le sens où il reprend la même interface, une partie de sa structure interne et le support des éléments de type Image. Par contre il ne prend pas en compte les aspects qui concernent :
Le développement de ce prototype présente plusieurs intérêts. D'abord, il a permis de décomposer la phase d'intégration du résolveur en ne traitant pas en même temps les problèmes spécifiques à Madeus (comme la définition de la syntaxe ou la présence de relations temporelles) et les problèmes concernant le positionnement spatial en général. Cela a permis de se concentrer sur l'intégration du résolveur dans un environnement interactif et sur la validation de l'algorithme de gestion des relations redondantes développé pour notre problème (section 0.0).
Ce prototype étant très proche de Madeus, il a permis de valider les premières fonctionnalités de placement spatial à intégrer dans celui-ci et a servi pour définir les aspects d'interface relatifs au placement spatial.
La raison de cette seconde phase de réalisation était de posséder un prototype d'expérimentation des techniques de propagation locale dans un environnement interactif indépendant de Madeus, lui même étant un prototype expérimental soumis à de nombreuses modifications. Il peut être réutilisé pour faire d'autres tests sur ces techniques, pour tester d'autres résolveurs de contraintes ou pour valider de nouvelles fonctionnalités à intégrer dans Madeus.
La troisième phase de réalisation de ce projet consiste en la mise en oeuvre du placement spatial à base de contraintes dans Madeus. Elle concerne la spécification syntaxique de ce placement dans les documents Madeus et l'intégration modulaire du résolveur DeltaBlue. Ce dernier point répond à la volonté de séparer clairement la partie déclaration des relations de la partie résolution afin de pouvoir changer de résolveur avec un minimum de modifications dans Madeus.
Concernant la syntaxe des documents Madeus, les modifications apportées se situent au niveau des attributs de positionnement des éléments et au niveau de la spécification des relations spatiales.
Ces attributs sont présents pour tous les éléments, exceptés les éléments de base de type Audio et sont introduits par la balise <POS> (Fig 3 ). Ils précisent les coordonnées relatives d'un élément par rapport à l'origine de son élément composite (Gauche, Haut), ainsi que ses dimensions (Largeur, Hauteur). La valeur de ces attributs est exprimée en pixels.
<OBJECT>
<NAME> BOUTON1
<FILEN> /samar/proto/streams/doc/CNAM/button.gif
<POS> {Gauche:78; Haut:24; Largeur:170; Hauteur:97}
<FORMAT> 6
<EOBJECT>
Les relations spatiales sont présentes au niveau de chaque élément composite pour spécifier le placement relatif entre ses éléments composés. Elles sont délimitées par les balises <SPREL> et <ESPREL> (Fig 4 ), et sont de la forme ElémentdeRéférence Relation ElémentSecondaire. Le jeu de relations défini est celui présenté à la section 0.
<SPREL>
BOUTON1 ALIGNEMENT_DROIT VIDEO1
BOUTON1 ALIGNEMENT_INFERIEUR VIDEO1
IMAGE2 CENTRAGE_VERTICAL TEXT2
IMAGE1 DECALAGE_SUPERIEUR(10) TEXT1
<ESPREL>
Les attributs de positionnement et les relations spatiales sont optionnels dans un document afin d'assurer la compatibilité de Madeus avec les anciens documents. Par contre, dès qu'un tel document est édité et sauvegardé, le nouveau format est pris en compte.
L'un des objectifs de ce stage était d'appliquer les techniques de résolution de contraintes par propagation locale dans le cadre d'un éditeur de documents multimédia. Nous avons expliqué dans le chapitre les raisons pour lesquelles nous avons décidé d'utiliser le résolveur DeltaBlue. Or, nous avons vu qu'il ne satisfait pas complètement les besoins pour ce type d'application. De plus, le domaine de la programmation par contraintes est un domaine très actif et il faut donc envisager à terme la possibilité d'intégrer un résolveur plus approprié. De ce fait, l'intégration de DeltaBlue dans Madeus devait être la plus modulaire possible. C'est pourquoi nous avons placé deux modules entre Madeus et DeltaBlue, le premier pour gérer les relations spatiales et pour les traduire sous forme de contraintes, le deuxième pour gérer le problème des relations redondantes présenté à la section 0. Ce dernier module, bien que non spécifique à DeltaBlue, a été développé pour pallier à un problème particulier de celui-ci et peut donc à terme devenir inutile avec un autre résolveur.
Nous ne reviendrons pas sur ce module dans la suite de cette section. Par contre, nous allons montrer le fonctionnement du module de gestion des relations et plus particulièrement ses interactions avec le résolveur DeltaBlue. La communication entre les deux s'effectue par l'intermédiaire de procédures définies à l'intérieur du module.
Cette procédure initialise la structure interne utilisée dans le résolveur.
Elle est exécutée une seule fois, lors du lancement de Madeus.
Cette procédure crée d'abord l'ensemble des variables pour un élément puis définit les contraintes intrinsèques de celui-ci :
Cette procédure est appelée lorsqu'un nouvel élément est défini, soit au niveau du document source pendant la phase d'analyse syntaxique, soit de manière interactive pendant la phase d'édition.
Cette procédure retire l'ensemble des variables d'un élément lorsque celui-ci est supprimé, c'est-à-dire lorsqu'il n'a plus de représentation graphique. Dans DeltaBlue, le retrait d'une variable provoque le retrait des contraintes portant sur celle-ci, en particulier des contraintes intrinsèques à l'élément.
Cette procédure est utilisée pour la suppression interactive d'éléments pendant la phase d'édition.
Cette procédure traduit d'abord la relation exprimée par l'auteur en une contrainte utilisable par DeltaBlue. Elle insère ensuite cette contrainte dans le système maintenu par celui-ci.
Elle est exécutée à chaque fois qu'une nouvelle relation active entre deux éléments est spécifiée. Cela peut être soit pendant la phase d'analyse syntaxique, soit pendant la phase d'édition.
Cette procédure supprime une contrainte gérée par le résolveur.
Elle est exécutée pendant la phase d'édition lorsqu'une relation active entre deux éléments est retirée.
Ces deux procédures créent chacune une contrainte d'entrée lorsqu'un élément est déplacé à la souris. Ces contraintes permettent la construction de deux plans, chacun d'eux contenant la liste ordonnée des méthodes à appliquer pour propager la perturbation provoquée par la contrainte d'entrée correspondante. Les plans constitués restent valides tant qu'aucune autre contrainte n'est ajoutée ni retirée et tant que le déplacement concerne le même élément.
Ces procédures sont exécutées pendant la phase d'édition lorsque l'auteur initie un déplacement d'élément à la souris.
Ces deux procédures exécutent en séquence les méthodes du plan respectif précédemment créé. L'intérêt de cette démarche est qu'elle évite de reconstituer les plans à chaque mouvement de la souris. Ce sont les mêmes plans qui sont exécutés tant qu'ils restent valides.
Ces procédures sont appelées pendant la phase d'édition, tant que l'auteur déplace l'élément pointé à la souris.
La principale difficulté pour l'intégration modulaire de DeltaBlue résidait dans le fait que celui-ci définit ses propres structures de données, notamment pour les variables et les contraintes qu'il manipule (0.0.0). Ces structures spécifiques ne doivent pas être référencées explicitement dans Madeus, or les variables représentent les paramètres des éléments (Gauche, Haut, ...) utilisés dans toute l'application. Ces informations sont donc définies à deux endroits : au niveau de la structure interne de Madeus avec un type indéterminé et au niveau de module de communication avec les structures de DeltaBlue.
Pour spécifier le placement des éléments pendant la phase d'édition du document, nous avons modifié l'interface utilisateur de Madeus présentée à la section 0.0.
L'interface utilisateur comporte deux palettes d'opérateurs supplémentaires permettant la saisie des relations spatiales et correspondant chacune à l'un des deux axes de référence (Fig 5 ). A chaque icône des palettes est associée une relation. Nous avons vu dans la section 0 qu'une relation d'espacement ou de décalage pouvait représenter plusieurs configurations selon la distance spécifiée. Nous avons fait le même choix au niveau de l'interface utilisateur et les icônes associées à ces relations symbolisent la configuration pour une distance positive. La configuration inverse est obtenue en spécifiant une distance négative.
Fig 5. Palettes d'opérateurs pour le placement spatial
Pour ajouter ou retirer une relation, l'auteur doit au préalable sélectionner les éléments concernés. L'élément sélectionné en premier est l'élément de référence de la relation. Le ou les éléments sélectionnés ensuite sont les éléments secondaires. Si l'élément de référence est retiré de la sélection, alors c'est l'élément sélectionné en second qui devient l'élément de référence. Les éléments sélectionnés sont mis en évidence par l'affichage d'un contour de couleur rouge pour l'élément de référence, de couleur verte pour les éléments secondaires.
Sur l'exemple de la Fig 6 , la sélection précède la définition d'une relation entre les éléments Choix2 (mise en séquence), Choix3 (accès au réseau) et Choix4 (promenade en Egypte) par rapport à l'élément Choix1 (extensibilité de Madeus).
Fig 6. Sélection d'objets
Après avoir sélectionné les éléments, l'auteur choisit dans la palette correspondante la relation qu'il veut spécifier. Pour les relations exprimant une distance entre les éléments, il doit également saisir cette valeur. Sur validation de son choix (bouton Apply) et si la relation est acceptée, alors le ou les éléments secondaires sont déplacés en conséquence. Si elle est refusée, alors un message d'erreur avertit l'auteur de la cause du refus.
La Fig 7 correspond au résultat de la relation Centrage_Vertical sur la sélection précédente. L'ajout d'une relation à partir d'une sélection comportant n éléments, avec n > 2 provoque la création de n-1 relations binaires, une entre l'élément de référence et chacun des éléments secondaires de la sélection. Sur notre exemple, le système a généré trois relations explicites : Choix1 Centrage_Vertical Choix2, Choix1 Centrage_Vertical Choix3 et Choix1 Centrage_Vertical Choix4.
Fig 7. Application d'une relation
Pour retirer une relation entre des éléments, l'auteur les sélectionne au préalable puis choisit l'option de retrait dans la palette correspondante (la première icône de chaque palette). S'il n'y a pas de relation entre les éléments sélectionnés sur l'axe correspondant, alors un message d'erreur avertit l'auteur.
Le retrait d'une relation à partir d'une sélection comportant n éléments provoque le retrait de la relation existante sur l'axe correspondant entre l'élément de référence et chacun des éléments secondaires de la sélection.
Lorsque l'auteur déplace un élément, les éléments reliés avec celui-ci suivent le mouvement selon le ou les axes sur lesquels portent les relations. Sur l'exemple de la Fig 7 , le mouvement d'un des quatre éléments Choix provoque le déplacement des trois autres sur l'axe horizontal mais pas sur l'axe vertical.
Une option de l'interface permet de déplacer un élément sur un seul axe à la fois. Seuls les éléments reliés sur le même axe sont alors déplacés.
La mise en oeuvre du placement spatial s'est traduite par des modifications dans le prototype Madeus et par la réalisation du gestionnaire spatial. Les modifications ont porté sur l'aspect syntaxique des documents et sur l'interface utilisateur. La réalisation du gestionnaire spatial a consisté d'une part à intégrer le résolveur DeltaBlue et d'autre part à développer les modules de traitement des relations et de gestion des relations redondantes.
La réalisation de ce gestionnaire nous a permis de constater les apports des techniques à base de contraintes pour le développement d'une application. Ces apports concernent principalement trois aspects :