Nous avons aussi complété la librairie d'ICON par des dispositif d'acquisition d'image, basés sur la librairie Java Media Framework [Sun Microsystems, Inc2005]. Cet ensemble de dispositifs permet l'accès bas-niveau à des périphériques tels que des webcams ou des cartes d'acquisition vidéo connectées à la machine hôte. Ces dispositifs (voir figure C.2) permettent l'émission d'images dans des configuration d'entrée, sous la forme de signaux ponctuels à déclenchement contrôlé par un événement (capture d'une image) ou en flux continu (capture video).
Des dispositifs adaptateurs asynchrones dédiés au traitement des images peuvent être réalisés à
partir d'un squelette de dispositif. Celui-ci permet d'externaliser les algorithmes de traitement
d'images à l'aide du principe des entrées/sorties implicites, assurant que ces dispositifs coûteux
en ressources ne pénaliserons pas l'exécution réactive de la configuration d'entrée (la thèse de
Pierre DRAGICEVIC donne plus de détails sur la réalisation de dispositifs à haut débit
d'informations).
Parmi les adaptateurs, nous proposons un dispositif de conversion d'images et un filtrage des
couleurs. Le premier permet la conversion vers différents types d'images (pour l'affichage, par
exemple, comme dans la figure C.2(b)). Le second peut permettre le contrôle d'un curseur
par suivi de gestesC.1, comme présenté dans la figure
C.2(c).
Enfin, un nouveau dispositif système permet de jouer des fichiers audio (en complément de celui d'origine qui n'utilisait que les périphérique de sortie de type Midi). Il permet de configurer simplement un retour sonore dans les interfaces, en spécifiant dans la configuration d'entrée l'action qui va déclencher le son.
Interpréteur de gestes
Le dispositif de reconnaissance de gestes que nous avons développé dans ICON facilite la
réalisation d'interfaces gestuelles (voir figure C.3(a)). Il utilise les
interpréteurs de la bibliothèque Satin [Hong et Landay2000], ainsi que l'outil Quill
[Allan Christian Long, Jr et
Landay1999,Allan Christian Long, Jr2001] pour la création et l'édition interactive des gestes.
À partir des entrées reçues (position et activation), le dispositif analyse la marque tracée conformément aux gestes définis. Il émet alors le nom et le groupe (les gestes peuvent être regroupés par catégories) du geste reconnu, ou la commande «unrecognized», et les informations géométriques sur le geste tracé (sa boîte englobante et ses points de départ et d'arrivé). Ainsi, de nombreuses configurations avancées peuvent êtres construites autour de ce dispositif, de la simple commande gestuelle, jusqu'à la sélection d'objets comme nous l'avons fait pour la saisie des contraintes dans SVALABARD (voir les sections 4.3.2 et 8.4.3).
Ce dispositif est interchangeable avec d'autres dispositifs de commande (clavier, reconnaissance vocale, etc.), permettant ainsi d'ajouter facilement de la reconnaissance de geste dans une application, même si celle-ci n'était pas à l'origine prévue pour.
Par exemple Pierre DRAGICEVIC avait utilisé le contrôle vocal pour manipuler une barre de défilement dans une application Swing (voir figure C.4(a)). Le dispositif de reconnaissance vocale émet les commandes reconnues (plus, un peu moins, minimum, etc.) qui sont alors envoyées au dispositif de contrôle conditionnel switch (qui active une commande en fonction de la chaîne de caractères reconnue). En remplaçant le dispositif de reconnaissance vocale par celui de reconnaissance de gestes, en ayant au préalable défini un vocabulaire de gestes compatible (voir figure C.4(b)), il est alors possible de manipuler la barre de défilement à l'aide de gestes. Des configurations plus complexes pourraient être construites en utilisant les informations sur la marque tracée pour déterminer l'objet d'intérêt (sélection de la barre de défilement) et le taux de défilement, par exemple.
|
L'implémentation des Marking Menu que nous proposons en fait une technique générique, sous la forme d'un dispositif. Dans la figure C.5, nous avons représenté ce dispositif connecté dans une configuration, sa boîte de paramètres et son retour graphique. Le menu est contrôlé par une souris et activé par le bouton gauche. Il faut ensuite configurer quelques paramètres, en particulier les items du menu: ceux-ci sont saisis dans des zones de textes de la boîte de paramètres. Le retour graphique du menu sera créé selon ces items, dont nous avons limité le nombre à sept C.2.
Les autres paramètres du dispositif sont les options graphiques (taille, couleurs, opacité, tracés et police) et les options de comportement du menu: délai avant l'apparition du menu ou de ses sous-menus, taille de la zone centrale. Le menu peut alors être utilisé dans la configuration: un clic sur le bouton de la souris permet de l'activer. Au bout du temps paramétré, le menu apparaît et permet de sélectionner l'item voulu, validé par le relâchement du bouton (un retour en zone centrale annule l'action). Si un item a été choisi, son nom est alors émis par le slot de sortie command du dispositif. Évidemment, si le geste est terminé avant le délai d'apparition du menu, le comportement est le même (envoi du nom de l'item correspondant au geste). Ce slot de sortie de commande peut être connecté à un dispositif switch, qui converti la chaîne de caractère reçue en une commande pour l'envoyer à un dispositif de contrôle (application ou outil), comme dans la figure C.5.
Enfin, plusieurs de ces dispositifs peuvent être composés afin de créer des cascades de sous-menus. Il faut pour cela utiliser les slot de sortie sub du dispositif. Le slot sub.this d'un menu de niveau N permet de le connecter au slot d'entrée parent de son sous-menu de niveau N+1. Ensuite, les slots de sortie sub.command, sub.x et sub.y permettent le contrôle du sous-menu.
|
La figure C.6 illustre de telles associations. Il y a tout d'abord un menu
principal, le dispositif Main menu. Celui-ci propose les commandes «open», «new»,
«save», «close» et «quit». La sortie principale (command) de ce dispositif est
connectée à un dispositif Switch qui va être assigné au traitement des items qui ne nécessitent pas
de sous-menu: «open», «close» et «quit». Par contre, les items «new» et «
save» nécessitent un sous-menu: la sortie sub.command va donc être connectée à un autre
dispositif Switch qui va traiter les commandes «new» et «save» afin de les repartir sur
les dispositifs de sous-menu. La commande «open» est transmise au sous-menu New menu, la
commande «save» au sous-menu Save menu.
Le sous-menu New menu propose alors six items: «class», «package», «beans»,
etc. Ces sorties sont elles-mêmes connectées à un dispositif Switch qui va traiter les commandes
émises par ce menu. Dès lors, lorsque l'utilisateur choisis l'item «new» du menu principal, le
sous-menu New menu apparait et propose six nouveaux items. Il en est de même pour l'item «
save» qui déclenche le sous-menu Save menu, pouvant lui aussi déclencher le sous-menu
SaveAs menu.
Nous accordons qu'une telle configuration peut paraître assez complexe, mais elle obéit à une simple logique d'aiguillage des signaux, propre à l'architecture en flot de données qui est assez vite assimilée de par sa logique. Bien que l'utilisateur final puisse modifier les configurations, cela reste tout de même plus le travail du concepteur de l'interface. Nos dispositifs lui permettront de créer très rapidement des Marking menu, de les tester, les raffiner et les réorganiser sans même avoir à écrire une seule ligne de code. Et il est encore une fois évident que des configurations alternatives peuvent être proposées (reconnaissance vocale, gestes, etc.).
|
Le premier, nommé inputRecorder, est un dispositif d'enregistrement que l'on peut intercaler à n'importe quel point d'une configuration d'entrée. Par exemple, dans la figure C.7, il se situe entre le dispositif souris et les adaptateurs qui lui sont normalement connectés pour propager ces valeurs dans le reste de la configuration. Lorsque la configuration est lancée, le dispositif d'enregistrement accumule toutes les valeurs qu'il reçoit des dispositifs qui lui sont connectés, la souris dans notre exemple. Bien entendu, il ne bloque pas ces valeur et les transmet par ses slots de sortie. Lorsque la configuration d'entrée est stoppée, le dispositif sérialise ces données accumulées dans un fichier XML.
Dans cet exemple, les données enregistrées sont reçues directement d'un périphérique d'entrée afin d'enregistrer tous ses déplacements et actions. Il serait évidemment possible d'enregistrer les sorties d'autres dispositifs, en utilisant même plusieurs enregistreurs dans une configuration.
Les données recueillies pourront ensuite être analysées pour des mesures de performance ou un simple suivi des actions réalisées. Mais il est aussi possible de «rejouer» les actions qui se sont déroulées en utilisant le dispositif virtualUser.,Il permet de re-émettre des données enregistrées dans une configuration d'entrée. Il peut être connecté dans la même configuration d'entrée, en lieu et place du dispositif d'enregistrement (voir figure C.8) et de tous les dispositifs qui lui étaient connectés afin de simplement «rejouer» les actions enregistrées. Il peut aussi être connecté dans une configuration alternative, comportant des dispositifs d'analyse, ou même d'autres interactions compatibles avec les données enregistrées.
|
Ces dispositifs peuvent aussi cohabiter dans une même configuration. Il est alors possible de définir un tampon d'échange entre eux (à l'aide des paramètres des dispositifs). Ce tampon peut servir, par exemple, à l'enregistrement d'actions répétitives qui pourront alors être rappelées dans le même contexte et lors de la même tâche, dans l'esprit de macros. Il serait alors envisageable d'étudier les possibilités de telles configurations dans le cadre de paradigmes de programmation par démonstration.
stuf