3832223710

dćcrit a la fin dc ce chapitre sera probablcment bientót une rćalitć. Mais aujourd’hui encore, un auteur d*objcts collaboradfs- cxplicatifs distribues ne dispose pas d*instruments dc composition approprićs.

Meme quand on peut intcrccptcr des ordres en Al pour les injecter en A2, on doit resoudre des probl&mes supplćmentaircs. Par exempie, nous devons concilier les ordres k distance avec les ordres locaux ("floor control") et realiser un ^u awareness ” qui donnę aux partenaires la possibilitć de s*observer adequatement. Nous devons aussi resoudre les probtemes poses par les diffćrences entre les contextes des deux applications liees. Les moniteurs peuvent avoir des dimensions diffćrentes ou etre rćglds sur d’autres resolutions. Les processus peuvent se derouler avec des temps differents d*exćcution. Les fenetres des applications peuvent etre placees et dimensionnees diffćremment. Les variabies de systóme inscritcs dans les registres des ordinateurs peuvent aussi differer. Ainsi la transposition d’un geste, d^łun contexte vers Pautre peut rćclamer une adaptation ou une reduction des libertćs de manoeuvre.

La rćalisation d*une "application panagee" sur deux plates-formes identiques par la programmation explicite des deux repliques correlees est complexe mais pourtant faisable. Pour faciliter la composition des demonstrations de type "shared work ”, le mieux serait de disposer d’un unique outil “d^uthoring ”, applicable sur toute application destinće a rexplication a distance. En passant de la demonstration d’une application a la dćmonstration d'une autre, Pauteur utiliserait les memes mecanismes de composition. II s’occuperait seulement de la physiologie d^monstrative superposćc sur la couche des applications, sans etre oblige de modifier leur codę, auquel d’ailleurs il n’a genćralement pas acces. Les mecanismes de partage devraient etre englobes dans la meta- application dćmonstrative et non pas infuses dans Tapplication dćmontrće. Mais comment intercepter, interpreter, retransmettre et traiter les actions de Puńlisateur sur la fenetre de Tapplication sans entrer dans son programme? L’essai d^łagrandir la reproductibilite de la solution se heurte a de grandes difficultds a cause de la maniere de contróler les applications utilisćes par les systćmes d*operation actuels.

Nous avons essayć de realiser la “fenetre de glace ” BI, superposće sur Papplication Al qui devait intercepter les gestes pour les transmettre vers la fenetre- soeur B2 qui couvrait A2. Ici on injcctait les ordres reęus dans la “queue d’anente ” que le systeme d*općration Windows utilisait pour satisfaire les commandes de Putilisateur local. Cette technique devait respecter le modę de gestion des interfaces, supporter les changements dynamiques des fenćtres, depasser la difficultć du mixage des gestes locaux et repliqućs, permettre “ Pawareness ”, soutenir les commentaires et les annotations. Mais le fait de preparer les rćactions dćmonstratives “au dessus ” de la couche de Papplication nous isolait des mecanismes d*interprćtation des gestes i 1'intćrieur de Papplication. L*auteur ćtait oblige ainsi i un effort important d*interpretation supplementaire, difficile a synchromscr avec cellc de Papplication, surtout si on permettait la modification

120