Un modèle de briques pour réaliser des interfaces graphiques:
le toolkit Ubit
Eric Lecolinet (elc@enst.fr) - ENST Paris / Dept. INFRES - CNRS URA 820
1. Motivation et Objectifs
L'expérience montre qu'il est souvent difficile et plutôt laborieux de créer
des objets graphiques sophistiqués spécifiques à un type d'application donné
en utilisant la plupart des toolkits graphiques actuels. D'autre part, les APIs
des toolkits courants sont souvent
excessivement compliquées et peu génériques. En particulier, la gestion
de l'interaction est généralement assez primitive et se résume pour
l'essentiel à l'implémentation d'une nuée de fonctions de "callback"
ou équivalent (par exemple les soit-disant "signaux").
Ceci constitue un frein important au développement de nouvelles techniques
d'interaction, et plus particulièrement - en ce qui nous concerne -
de techniques de visualisation de l'information. Plusieurs projets
de recherche ont tenté de résoudre ce problème dans le passé mais
force est de constater que ces projets ont rarement dépassé le cadre
des laboratoires de recherche. Ceci est particulièrement sensible
dans le "monde C et C++", où les toolkits récents (Qt, Gtk) semblent
pour l'essentiel ignorer les acquis de ces recherches passées
(par opposition au "monde Java" ou le modèle Java/Swing peut constituer
un début de solution intéressant à certains des problèmes cités).
Notre objectif est de réaliser un toolkit C++, multi-plateformes
(X-Window et Windows), "domaine public" (plus exactement sous "licence GPL")
qui serve de "laboratoire d'idées"
pour tenter de résoudre ces problématiques. Ce nouveau toolkit
est (et sera) orienté autour des principes listés ci-après.
A. Généricité et (relative) simplicité de l'API
Les APIs habituelles sont généralement insuffisamment génériques et
font apparaître trop de "détails" liés à des contraintes d'implémentation
bas niveau, ce qui complique l'implémentation et
l'évolutivité des interfaces (en particulier dans le cadre d'un
processus itératif de conception / implémentation de systèmes interactifs.)
D'autre part le code nécessaire à l'implémentation des interfaces tend souvent
à être excessivement verbeux et peu compréhensible (exemples typiques:
Motif ou Gtk) faute d'APIs génériques, bien construites et suffisamment
"haut niveau".
B. Flexibilité et évolutivité des objets graphiques
Le système doit favoriser la créations d'objets nouveaux, spécifiques
à une application donnée et/ou utilisant des techniques non conventionnelles.
Ces nouveaux objets doivent pouvoir être créés en écrivant le moins
de code possible via la réutilisation et la combinaison d'objets
déjà existants.
C. Unification interfaces conventionnelles vs. hypertexte
Le toolkit doit tendre a réduire la fracture artificielle (car essentiellement
historique) qui existe actuellement entre le monde des interfaces graphiques
"classiques" et celui du document structuré et des hypertextes.
Cette fracture n'a en grande partie plus lieu d'être comme de démontre
assez clairement l'évolution des interfaces sur le Web.
D. Simplification de l'interaction
Le recours aux fonctions de callback doit être minimisé. Au contraire,
le système doit permettre de spécifier un maximum de comportements
soit implicitement via des règles structurales bien définies,
soit explicitement via des spécifications déclaratives ou des contraintes.
E. Nouvelles techniques d'interaction et Visualisation de l'Information
A terme, le but est d'incorporer un certain nombre de caractéristiques
"standard" (zoom, transparence...) dans le toolkit pour faciliter
l'implémentation d'interfaces mettant en oeuvre des techniques de
Visualisation de l'Information.
2. Solutions Proposées
Ubit diffère essentiellement des toolkits actuels par son architecture.
Habituellement, les "widgets" ou autres "controls" fournis par les toolkits
standard sont plutôt de "gros objets" gourmands en ressources
physiques implémentant quantités de fonctionnalités hétérogènes
généralement inutiles pour une tâche donnée - à l'exception de la
"fonctionnalité oublié" qui serait justement nécessaire pour l'application
que l'on est en train de réaliser. Ceci entraîne un manque de flexibilité
des objets existants, une adéquation insuffisante entre les objets fournis
et ce que l'on souhaite réaliser et un gaspillage excessif des ressources
physiques. De plus, la création d'objets nouveaux par sous-classage
est souvent un réel casse-tête du fait de la complexité et de
l'hétérogénéité interne des objets existants.
Par opposition, Ubit est essentiellement composé d'un ensemble de
briques de base:
-
réalisant des tâches simples et clairement identifiées
-
facilement combinables entre-eux.
Les "gadgets" de haut niveau ne sont que des combinaisons de briques
de bases et sont eux-mêmes des briques combinables avec d'autres objets.
Ceci permet de réaliser une grande variété d'objets "hybrides"
par simple combinaison d'objets élémentaires, préexistants ou spécifiquement
crées pour une application données. Ainsi la "richesse" du toolkit
ne provient pas des objets fournis de manière standard mais des possibilités
de combinaison et d'enrichissement de ces objets.
La propriété de "libre combinaison" permet par ailleurs de créer de
manière triviale des objets composites (mélangeant texte, images et
objets graphiques classiques), du pseudo-hypertexte, ou des objets
très spécifiques (typiquement en composant plusieurs gadgets entre-eux,
quelle que soit leur nature).
Cette architecture implique également des changements importants
dans la manière de gérer l'interaction dans la mesure où elle effectue
un transfert du contrôle vers les objets élémentaires. Cet aspect
est d'autant plus sensible que tous les objets sont partageables
ce qui introduit des contraintes structurales implicites délivrant le
programmeur de nombreuse tâches d'interaction et de synchronisation.
Par exemple, une fonte, une couleur, une "décoration" (les encadrements,
les ombrages, etc.), une chaîne de caractères (éventuellement éditable)
sont des objets à part entière qui peuvent être partagés par plusieurs gadgets.
Le contrôle de la valeur courante de ces objets élémentaire ne s'effectue
pas au niveau des gadgets mais via les objets élémentaires eux-mêmes,
tout changement de valeur étant automatiquement répercuté sur les gadgets.
Ces gadgets seront donc implicitement synchronisés du fait même
de la structure de l'interface (c'est-à-dire des liens qui lient les
objets dans le graphe d'instanciation).
Les gadgets sont eux-mêmes "partageables" dans la mesure où ils peuvent
également avoir plusieurs parents. Ceci implique deux types de conséquences
suivant la nature des objets concernés:
-
soit des comportements implicites si l'objet partagé possède une fenêtre
propre (typiquement un menu ou une boîte de dialogue) : par exemple tous
les boutons "parents" d'un menu ouvriront implicitement ce menu.
-
soit une représentation multiple en différents lieux de l'interface
de l'objet concerné. Cette capacité d'"ubiquité" permet
également de simplifier la synchronisation des objets dans la mesure
où toutes les représentations sont conditionnées par l'état courant d'un
objet unique (par exemple le texte contenu, le fait qu'un checkbox soit
sélectionné ou non, etc.).
Enfin, le toolkit offre un certain nombre de propriétés visant à simplifier
l'implémentation des interfaces. En premier lieu, deux APIs interchangeables
sont offertes au programmeur. La première est procédurale et plus ou moins
similaire à Java AWT. La seconde est pseudo-déclarative et permet de
spécifier les GUIs sous forme de listes imbriquées. Ces deux APIs sont
librement "mélangeables" et ne nécessitent pas l'utilisation d'un
pré-processeur particulier.
D'autre part, le toolkit remplace la classique notion d'événement
par celle d'état et de transition d'état. Chaque gadget incorpore un
gestionnaire d'états capable de déterminer à tout moment l'ensemble des
états courants de l'objet concerné (par exemple s'il est visible,
s'il est sélectionné, s'il est "pressé", si l'on est en train d'y entrer
du texte, etc.). Ceci permet en particulier de spécifier nombre de
comportements de manière pseudo-déclarative via la notion de propriété
conditionnelle. Il est en effet possible de définir de cette manière
quelle couleurs, quelles fontes, quelles décorations, quelles chaînes
de caratères, etc. seront effectivement affichées selon l'état de l'objet
(par exemple si on clique dessus, si la souris entre dans l'objet, etc.)
3. Etat courant et travail futur
Le toolkit Ubit est actuellement en cours de réalisation.
L'objectif à plus long terme est d'en faire un toolkit dédié
pour la visualisation de l'information. On s'intéressera en particulier
dans un premier temps aux possibilités de zoom quantique et de transparence.
D'autre part, la propriété d'ubiquité pourrait être étendue à la
réalisation d'interfaces distribuées pour la réalisation de collecticiels.
