Rapport Final du Projet d'application Evolution de l'implémentation de certaines fonctionnalités dans le module Impress d'openoffice

Transcription

1 Rapport Final du Projet d'application Evolution de l'implémentation de certaines fonctionnalités dans le module Impress d'openoffice Cyril Le Mat Arthur Bonnet Année 2009/2010

2 .I. Contexte du Projet... 3.I.1 Le concours HP... 3.I.2 Mise en contexte de l'environnement technologique (Tablet PC)... 3.I.3 Travail à effectuer... 4.II. Management du Projet... 5.II.1 Communication :... 5.II.2 Suivi de projet :... 5.III. Spécifications et Objectifs :... 8.III.1 Impératifs de langage et de codage... 8.III.2 Communauté et maintenabilité... 9.IV. Idées d'amélioration d'openoffice IV.1 Différencier le slide de ses annotations IV.2 Accès à l'autorisation du mode annotation dans le menu du clic droit du mode diaporama IV.3 Autoriser le retour arrière lors de la création d'annotations IV.4 Cadre de sélection IV.5 Primitives de formes de gomme IV.6 Reconstruction d'objets après gommage IV.7 Fusion d'objets dissociés V. Implémentation et difficultés rencontrées V.1 Téléchargement du code V.2 Compilation de la milestone V.3 Compilation d' ooo4kids V.4 Prise en Main de gdb et version debug V.5 Analyse du code V.6 Stratégie d'implémentation V.7 Implémentation VI. Amélioration de la reprise du projet par le prochain groupe VI.1 La préparation aux méthodes de travail propres à ce sujet VI.2 La centralisation des liens et des ressources sur le wiki VI.3 La centralisation des pistes d'amélioration d'impress VI.4 La forme particulière du rapport VI.5 Conclusion VII. Conclusion VIII. Annexe VIII.1 Téléchargement des sources avec Mercurial VIII.2 Compilation d'openoffice... 24

3 .I. Contexte du Projet.I.1 Le concours HP Les Tablets PC ont été obtenus par un concours à but pédagogique mais non lucratif organisé par HP sur le thème : «l utilisation du Tablet PC dans l enseignement». L OS des Tablets PC est actuellement sous Vista mais on a cherché à mettre en place une base d environnement sous logiciel libre qui soit utilisable pour les enseignants et les élèves, ces derniers étant les principaux destinataires. L objectif est de ne pas rester dépendant de Windows. Cette recherche était d ailleurs un des points développés par les enseignants pour gagner le concours. Ce projet de groupe s'est donc inscrit dans ce processus de mise en place de manière la plus transparente possible, le passage de Windows Vista à un OS libre le plus compatible possible, tout en assurant le maximum de fonctionnalités sous celui-ci, pour que les utilisateurs puissent s'y retrouver..i.2 Mise en contexte de l'environnement technologique (Tablet PC) Notre environnement technologique était donc orienté vers les Tablets PC, ce qui nous avait attiré vers OpenOffice dès le début du projet de Groupe. De plus nos développements devaient être faits en utilisant C++ et être compatibles impérativement avec les trois plateformes. De plus OpenOffice.org est un logiciel complexe possédant son propre système d'extension, avec un langage permettant d'interfacer le cœur du programme (en C++), avec d'autres langages comme Java/Python/... selon le modèle suivant : Java, C++, Python... UNO C+ + Noyau Interface Universelle Extensions

4 L'UNO, acronyme pour Universal Network Object, permet ainsi de gérer des extensions qui seront interprétées correctement par le noyau de l'application. Cela se traduit en terme de fichiers, dans le cœur d'openoffice, par beaucoup de fichier.idl : Interface Definition Language, et le compilateur associé Idlc. Ces fichiers servent de couches d'abstraction pour des programmes créateurs de code, qui ont besoin de générer des interfaces selon le modèle suivant : Mais notre projet consistant à modifier principalement le cœur d'openoffice nous n'avons pas vraiment été obligés d'entrer en contact avec de l'uno, même s'il fallait respecter certains standards de codage pour utiliser ou être compatible avec des composants UNO..I.3 Travail à effectuer Le projet consiste en l'amélioration de la prise en compte des fonctionnalités Tablets PC par OpenOffice. Il est un pendant du projet posé sur la gestion des enregistrements temporaires et persistants en mode diaporama. Ce projet fera l'objet d'interactions avec l'équipe de développement d'openoffice. Il se situe dans la continuité du projet de groupe mené sur le sujet, et vise à répondre à certaines des perspectives envisagées à l'issue de ce travail. Les travaux porteront notamment sur les points suivants : améliorer la gestion du canvas (zone intermédiaire sur laquelle il est possible de tracer des dessins/des annotations/etc. quand on visualise une slide) ; travailler sur l'apparition/disparition de fenêtres en overlay ; dessiner une primitive ; garantir la propreté et la robustesse du code produit pour que celui-ci soit soumis officiellement à intégration dans OpenOffice.org

5 .II. Management du Projet.II.1 Communication : Le projet de groupe a été l'occasion de lié des relations fortes avec la communauté OpenOffice.org. L'école est rentrée dans ce cadre dans le programme Education d'openoffice. Cette collaboration permet une communication rapide et représente une source d'information importante pour la réalisation du projet. Le mode de communication majoritairement employé est la conversation IRC dont les logs ont été conservés tout au long du projet et sont donc une trace et une source d'information utile lors de l'étude du code d'openoffice et du développement..ii.2 Suivi de projet : Le projet s est organisé suivant le Gantt présenté à la page suivante.

6

7 Cyril Le Mat : 70 heures 35 heures de compilations 5 heures de management (dont la rédaction des rapports d'avancement) 5 heures de réunion 10 heures d' analyse de code et de recherche de solution 5 heures de codage 10 heures pour la préparation de la soutenance (rapport final et présentation) Arthur Bonnet: 65 heures 10 heures de compilation 10 heures de prise en main de gdb et version debug 5 heures de management (dont la rédaction des rapports d'avancement) 5 heures de réunion 10 heures d' analyse de code et de recherche de solution 5 heures de codage 10 heures pour la préparation de la soutenance (rapport final et présentation) 10 heures de management wiki Suivi du projet avec le «client» : M. Magnin Les réunions ont eu lieu environ tous les 15 jours pour un suivi de notre évolution dans le projet et pour les recadrages éventuels. Au cours de ces réunions il a été convenu, comme nous l'avons précisé avant, du choix de l'implémentation à effectuer. Il a, par ailleurs, été mis l'accent sur la nécessité d'essayer d'avoir la meilleure communication possible avec la communauté sur notre projet.

8 .III. Spécifications et Objectifs :.III.1 Impératifs de langage et de codage OpenOffice.org est un projet Open Source énorme, il est une des références dans le monde libre, comme on a pu le voir dans la partie «contexte du projet», mais c'est aussi un projet sur lequel encore des nombreuses personnes travaillent chaque jour. A la fois des développeurs de Sun Microsystems qui continuent à réaliser un certain nombres de taches indispensables, (comme la gestion de l'internationalisation d'openoffice, par exemple), mais aussi des développeurs du monde entier qui contribuent à ce logiciel pour l'améliorer de manière bénévole, comme nous le faisons. Il serait impossible de maintenir dans un état opérationnel un tel logiciel sans un minimum de rigorisme et des impératifs de codage que tous doivent respecter. Tout d'abord le cœur d'openoffice.org est codé en C++, possède ses propres outils de compilations, et sa propre structure. Il est donc nécessaire de bien maîtriser C++ et son formalisme pour respecter les standards de codage du langage, comme par exemple : la séparation des fichiers d'en-tête et des fichiers d'implémentation. Mais à ces standards, on doit ajouter les impératifs de codage ou bonnes pratiques que l'on se doit de respecter au sein d'un projet. La séparation des fichiers évoquées ci-avant est un très bon exemple. En théorie, on se doit de respecter cette norme, mais lors de l'implémentation dans OpenOffice, cette norme se voit tempérée par la pratique, voire complètement abandonnée. En somme la séparation en fichier.hxx et.cxx d'une classe maclasse, n'est vraiment nécessaire et suffisante que lors que l'on doit pouvoir inclure dans un autre programme cette classe, via #include «maclasse.hxx» Alors même si on avait tendance à le faire pour toutes les classes, cela serait très pénalisant au niveau du temps de compilation, car le compilateur serait alors obligé de lire des fichiers d'en-tête, dont on pouvait se passer. Ainsi on retrouve souvent dans OpenOffice, des classes définies à l'intérieur même de leur fichier.cxx. Ce petit exemple permet de comprendre la somme des bonnes pratiques à intégrer pour un langage donnée pour pouvoir rejoindre un projet Open Source et contribuer de manière à ce que le code soit utilisable par la communauté. Il n'a pas été évoqué les problématiques de communication, le fait de commenter son code en anglais, ainsi que de pouvoir discuter de manière compréhensible avec les acteurs du projets, mais il est clair que la maîtrise de l'anglais était impératif pour pouvoir ne serait ce que commencer à entrevoir dans quelle direction orienter le développement.

9 .III.2 Communauté et maintenabilité Le fait de contribuer à un projet Open Source aussi important, nécessite de mettre toutes les chances de son coté pour que nos modifications soient intégrées à une future version d'openoffice.org. Il faut tout d'abord passer par le système de gestion des bugs d'openoffice, où se trouvent des différents bugs repérés par la communauté d'openoffice. Si le bug est nouveau, il est d'ailleurs nécessaire de créer un ticket le spécifiant. Ensuite une fois le bug confirmé et la demande réelle, il faut entamer le processus de spécification d'openoffice, visant à permettre la gestion de spécifications fines pour implémenter en connaissance de cause les meilleures options. Ce processus est très lourd et prévoit pour les cas les plus extrêmes une analyse concurrentielle et une étude de marché de ce qui se fait dans le domaine, ainsi que des schéma précis des modifications que l'ajout de cette fonctionnalité va entraîner dans l'interface utilisateur. Une fois ce processus terminer, il est nécessaire d'envoyer le document créé aux équipes de spécification pour validation

10 Voici un exemple d'un tel document:

11 .IV. Idées d'amélioration d'openoffice.iv.1 Différencier le slide de ses annotations On peut considérer que les annotations sont des rajouts sur une présentation. En effet on imagine qu'elles sont crées une fois que la diapositive a été présentée, l'audience a alors intégré le sens de cette diapositive, et qu'elles surchargent et/ou gênent la lecture. Le format d'annotation est cependant intéressant et surtout différent de celui des informations inscrites «en dur» dans la diapositive. Dans le cas d'annotations pertinentes conservées, le présentateur ne souhaitera pas les montrer en même temps que la diapositive pour ne pas surcharger celle-ci et aussi parce que les annotations ne deviennent intéressantes qu'après avoir expliciter le contenu de la diapositive en question. A ce titre il serait intéressant d'autoriser le basculement entre un affichage avec les annotations ou sans. On pourrait imaginer que ce basculement ne serait effectuer que pour une seule diapositive (je suis sur la diapositive n en mode normal, je bascule en mode affichage d'annotations mais je veux que lorsque j'appelle la diapositive n+1 le mode par défaut soit le mode sans annotations). Le présentateur aurait ainsi la possibilité de moduler sa présentation comme il le souhaite..iv.2 Accès à l'autorisation du mode annotation dans le menu du clic droit du mode diaporama Actuellement, l'activation du mode annotation est longue (menu Slideshow puis Slideshow settings et enfin check box «mouse pointer as pen»). En particulier lors de l'utilisation d'un tablet PC, l'activation de cette option semble intuitive et il est dérangeant qu'il faille aller cherche si loin pour l'activer. Nous proposons donc que cette option soit beaucoup plus accessible (peut-être même éventuellement activée par défault étant donné qu'on utilise rarement le clic pour changer de diapositive mais plutôt le clavier) par exemple dans le menu du clic droit pendant le mode diaporama..iv.3 Autoriser le retour arrière lors de la création d'annotations Dans le but de faciliter la création d'annotation nous pensons qu'il serait intéressant d'introduire les fonctions usuelles de retour arrière (aussi connues sous le nom de leur raccourci clavier ctrl+z ou pomme+z). Ces fonctions permettent d'annuler la dernière action (on entend usuellement par dernière action, les évènements survenus entre le moment où le bouton a été enfoncé et le moment où il a été relâché) voire même les dernières actions, le nombre d'actions accessible restant alors à définir. Bien que le résultats de ces fonctions puisse être obtenu de manière différente (utilisation de la gomme ou sélection d'objet), c'est un usage répandu et intuitif pour un utilisateur. Aussi nous pensons qu'openoffice doit être tourné vers l'utilisateur et donc proposer toute fonctionnalité qui rendrait l'expérience utilisateur plus rapide et plus intuitive. Le ressenti de

12 l'utilisateur quant à l'absence de fonction retour arrière sur les annotations serait préjudiciable à son appréciation globale du logiciel malgré que ce soit là un détail..iv.4 Cadre de sélection Toujours dans l'objectif d'une meilleure manipulation des annotations et d'une meilleure expérience utilisateur nous pensons que l'implémentation d'un cadre de sélection pendant le mode diaporama serait une réelle amélioration. En effet on pourrait ainsi faciliter la sélection d'objets de manière à pouvoir les déplacer, copier ou encore supprimer. C'est, là encore, l'absence d'une telle fonctionnalité qui laisse une impression mitigée à l'utilisateur..iv.5 Primitives de formes de gomme Actuellement la gomme se présente sous la forme d'un carré de différentes tailles. Pour plus de précision dans le gommage il serait avantageux d'introduire une forme ronde qui, pour une taille équivalente, occupe une surface moindre de manière à gommer exactement ce que l'on désire. Aussi pour Ooo4Kids, il serait judicieux d'introduire des formes de gommes plus fantaisistes comme par exemple une étoile, un triangle voire des formes d'animaux. Ce serait-là un point qui renforcerait le caractère ludique, caractère renforcé d'autant plus lors de l'utilisation d'un tablet PC. On peurrait néanmoins imaginer que ces formes moins standards ne seraient pas directement accessibles dans OpenOffice standard..iv.6 Reconstruction d'objets après gommage La gomme fonctionne aujourd'hui en rajoutant un calque blanc par-dessus l'annotation. D'un point de vue intrinsèque, l'objet n'est donc pas modifié lors d'un gommage. Pourtant il apparaît comme tel à l'affichage. Aussi lorsqu'on gomme une partie d'une ligne sur une feuille de papier, on efface cette partie ce qui signifie deux choses : on ne la voit plus et elle n'existe plus. Cette deuxième conséquence n'est pas encore implémentée sous Impress. Ainsi lorsqu'on sélectionne un objet en partie gommé, c'est tout l'objet qui est sélectionné et il n'est pas possible de faire autrement. Le fonctionnement désire consisterait à séparer «physiquement», non seulement au niveau de la visualisation, les différentes parties d'un objet crées du fait du gommage. Une ligne dont on gommerait le milieu deviendrait alors deux lignes indépendantes et manipulables comme n'importe quel objet. Ce serait là une fonctionnalités transparente pour l'utilisateur mais qui offrirait de réelles possibilités en termes de manipulations d'annotations.iv.7 Fusion d'objets dissociés Plus dirigée vers des aspects ludiques (OOo4Kids), nous avions pensé à une fonction «duale» de celle décrite précédemment qui divise un objet en plusieurs. Nous imaginerions une fonction qui permette de fusionner deux objets en un seul. Par exemple, nous avons deux lignes distinctes à partir desquelles nous souhaitons créer un objet unique. Cette fonction permettrait de raccorder ces deux objets pour n'en faire qu'un seul. On peut imaginer que lorsqu'on approche un objet d'un autre dans le but de les fusionner une sorte d'aimant vienne «arrimer» le deuxième objet sur le premier.

13 Les objets devraient alors peut-être être dans des configurations spécifiques : il paraît difficile de fusionner une courbe fermée avec une qui ne l'est pas par exemple. Nous redoutons que cela suppose des analyses sur la géométrie des objets qui soient trop poussées pour le résultat, mais cette piste demeure néanmoins à explorer.

14 .V. Implémentation et difficultés rencontrées Cette partie est un peu plus technique et va rentrer dans le détail de l'implémentation, ainsi que dans les choix effectués et les difficultés qui ont été affrontées, tant au niveau de la compilation que dans l'implémentation. De plus, étant donné le volume de code d'openoffice, le répertoire de développement faisant 8.35 Go après compilation, les fonctionnalités d'auto-complétion d'eclipse n'aurait pas été utilisable, et comme OOo possède son propre mode de compilation, Eclipse ne nous offrait alors pas plus d'avantage que Gedit ou Xcode, qui ont été nos outils principaux. Si nous ne devions retenir qu'une leçon de cette expérience, ce serait que pour réaliser du bon travail sur un projet aussi important, il faut accorder une attention particulière à la mise en place de la plateforme de développement, et ne pas sous-estimer l'étude de moyen pour optimiser sa manière de réaliser des tâches récurrentes, comme nous le verrons dans la suite du chapitre. Voici les différentes étapes de mise en place du projet:.v.1 Téléchargement du code A la base proposé avec mercurial, le code fut téléchargé de nombreuses fois de suites par chaque membre du binôme, soit par Mercurial, soit par SVN. Cyril Le Mat a rencontré des problèmes pour télécharger son code car le tablet pc a notre disposition souffrait de conflit entre sa partition windows et sa partition linux. En effet, la seule partition disposant d'un espace nécessaire au projet était la partition Windows qui n' acceptait pas le téléchargement des sources par svn ou mercurial. Il a donc été décidé de formater la partition windows. Suite à cela, d'autres problèmes ont été rencontrés, en effet, un premier formatage du disque dur en fat32 ne permettait pas non plus d'effectuer le projet. Il a fallut reformater le tablet PC avec un format ext3, plus apte à supporter la compilation d'open office. Arthur Bonnet n a pas eu de problèmes concernant le téléchargement du code. Il conseil néanmoins d utiliser les night bundle (fichier dev300.hg) plutôt que de tout télécharger d un seul coup..v.2 Compilation de la milestone 12 Nous avons premièrement tenté de compiler la milestone 12, La fin de la compilation a pris effet le 18 février La configuration de Cyril pour la m72 sous Ubuntu :./configure -with-use-shell-bash -with-system-libs -without-system-jars -without-system-icu - without-system-agg -without-system-lpsolve -without-system-mspack -disable-mozilla -disablebuild-mozilla -disable-ok -with-system-python --without-stlport --disable-binfilter --disable-odk -- with-system-hunspell=no --enable-presenter-extra-ui --with-ooo4kids --enable-presente-extra-

15 ui --with-java=no Cette compilation fut longue car elle nous confronta a de nombreux problèmes tels que: -apprentissage de linux -formatage de la partition windows du Tablet PC pour pouvoir télécharger les sources Arthur a effectué, pour sa part, la compilation sous opensuse sans rencontrer de problèmes particuliers sauf pour une certaine milestone comme détaillé dans la partie suivante..v.3 Compilation d' ooo4kids Nous avons finalement porté notre attention sur le fait de compiler une version d' ooo4kids sur la quelle le module eraser était implémenté. Nos sommes le 19 février. Ce choix a été fait car ooo4kids est plus stable et plus rapide à compiler que la milestone 71 d'open office, dernière milestone sortie au moment de ce projet. Après de nombreux problèmes techniques, nous somme venus à bout de la compilation le 3 mars Remarque: Lors de la configuration de cette compilation, nous avons remarqué qu'il était nécessaire d'avoir le paquet libgstreamer0.10-dev installé sur l'ordinateur effectuant la compilation. C'était une information non connue de la communauté d'open office, elle a donc été rajoutée au wiki pour servir au futurs personnes qui tenteront de compiler ooo4kids. la configuration de Cyril D'OOo4kids sous ubuntu $./configure --disable-binfilter -disable-odk --with-lang="fr" --disable vba --disable-mozilla --with-system-python --with-system-libxml -- enable-cups --disable-fontconfig --disable-gnome-vfs --with-use-shell=bash --with-java=no --with OOo4Kids --with-package-format=installed --disable-gtk --enable-presenter-extra-ui Arthur, Sous opensuse, malgré une compilation sans accroche d OOo a eu des problems pour compiler OOo4Kids. Il a donc décidé de revenir sur la dernière milestone d OOo (m75) avec laquelle il n'a eu aucun problème (attention cepandant à la milestone m71 qui nous a posé des ennuis). En conclusion, en cas de problème on peut essayer de compiler une milestone antérieure (demander à qui de droit les numéros des milestones stables) ou encore de compiler OO4Kids (plus rapide à compiler mais plus gourmand en mémoire disque)..v.4 Prise en Main de gdb et version debug Pour générer les librairies à la compilation, il existe plusieurs options, notamment celle de «debug=true». Elle permet de donner plus d'informations lors du lancement du logiciel dans un terminal. Lors de la réalisation des tests, il se peut qu'un bug survienne (segmentation fault par exemple) ou bien que le comportement ne soit pas celui attendu. D'où l'utilisation massive du debugger classique

16 en C/C++ : gdb. On lance gdb avec le lanceur soffice.bin. Puis, on lance le programme par la commande run. L interface du debuggeur est en ligne de commande, ce qui peut être un peu déroutant au premier abord, il convient donc de se faire un peu la main. Le debugger gdb, en ligne de commande, permet de parcourir l'execution du code pas à pas pour chaque fonction (commande step) ou sans rentrer dans les sous-fonctions (commande next). Il permet aussi d'afficher la pile d'instructions exécutées (commande backtrace), d'afficher le contenu de variables (commande print), enfin de fixer des points d'arrêts (breakpoints) par la commande breakpoint. Le suivi des instructions peut aussi se faire visuellement dans le terminal en activant ce mode par la commande Ctrl+X puis a. Ce mode affiche le code sur la moitié haute du terminal. Ce mode donne ainsi le fichier et la ligne où se trouve l'exécution, ainsi que son adresse en hexadécimal. Le code est affiché uniquement s'il a été compilé en mode debug. S'il n'est pas affiché, il est quand même possible de suivre l'exécution des instructions grâce des commandes assembleurs (par exemple : stepi). La prise en main de gdb s est faite avec des tutoriaux en ligne (siteduzéro) et des ressources du site d Eric Bachard. Les liens sont disponibles sur le wiki.

17 .V.5 Analyse du code L'analyse du code fut une étape assez longue. En effet celui ci est très complexe, ce qui s'explique en grande partir par la taille du projet qu'est OpenOffice. Cependant, certains éléments du code ne sont pas très clairs et très enclins a être facilement réutilisable, par exemple, certain noms de variables représentent des variables de types différents suivant les classes rencontrées. Par exemple : -dans slideshowimpl, mapolygons fait partie de la classe mappolygon -dans b2spolypolygon.cxx, mapolygons fait partie de la classe PolyPolygonVector De plus, certaines classes font appel à des variables globales peu clairement définis rendant très contraignant leur réutilisation. Par exemple : -les classes b2dpolypolygon.cxx et b3dpolypolygon.cxx, bien que définissant des méthodes sur les PolyPolygonVector, utilisent constamment la variable globale mapolygons, ce qui rend inutilisable ces méthodes avec d'autres objets de PolyPolygonVector..V.6 Stratégie d'implémentation Nous avons abouti à une stratégie pour résoudre notre problème. L'idée: -créer un double de mapolygons(polygon comprenant tout les annotations de chaque slides sous formes de Polygones) appelé mapolygonserased conprenant tout les traits déssinés en mode gommes. -effectuer par la suite une opérations ensembliste pour pouvoir soustraire au traits de mapolygons les intersections de ceux ci avec les traits de mapolygonserased de manière à obtenir dans l'objet mapolygons les annotations gommées. Voici un exemple simple de la stratégie d'implémentation: -Voici une annotation tracée en mode "pen", celle ci est donc conservée dans le mapolygons contenu de mapolygons

18 -Voici un coup de gomme tracé lors de la même slide conservé dans le mapolygosnerased contenu de mapolygonserased -Nous pouvons donc réactualiser la valeur de mapolygons en lui soustrayant les polygones de mapolygonserased contenu de mapolygons Voici un diagramme d'activité résumant la stratégie de fonctionnement de notre modification :

19 .V.7 Implémentation voici notre plan d'implémentation en quatre étapes: 1. déclarer mapolygonerased dans les différents fichiers nécessaires dans plusieurs fichiers du module slideshow : -slideshowimpl.cxx -userpaintoverlay.cxx -userpaintoverlay.hxx -slideimpl.cxx 2. quand on efface avec la gomme, rajouter les traits produits avec la gomme dans PolygonErased -modification de la fonction virtual bool handlemousedragged( const awt::mouseevetn& e )de userpaintoverlay.cxx 3. créer une fonction merge(p1,p2) effectuant l'opération assembliste P1 -P1interP2. Ces opérations de base sont disponibles dans les méthodes despolypolygon dont déscend la classe de mapolygon -Méthode à rédiger dans la classe SlideShowImpl 4. faire appel à cette fonction merge quand on sort du mode diaporama() quand on fait appel à la méthode registeruserpaintpolygon de SlideShowImpl Résultats: Tout ces développements ont été effectués sauf la fonction merge, qui avait initalement été remplacé par une fonction merge plus simple en vue de tester la cohérence du reste du code. Seulement, un problèmes est survenu à la compilation et nous n'avons pas eu le temps de le résoudre, le planning arrivant à sa fin. Nous avons donc du faute de temps, arréter à cette étape la démarche d'implémentation pour nous concentrer sur les autres contributions que nous pouvions apporter au projet.

20 .VI. Amélioration de la reprise du projet par le prochain groupe Ce projet est, parmi les autres projets d'application, singulier. En effet le travail sur lequel il porte a été initié avec un projet de groupe l'année dernière. Deux projets d'application suivirent sur lesquels ont travaillé des membres du projet initial. Cette année un projet de groupe été mis en place jusqu'au présent projet d'application qui représente donc le cinquième des projets sur Education OpenOffice. Bien que ce dernier soit un projet à part entière, il demeure inscrit dans la continuité des autres, dans un contexte familier de l'équipe enseignante de L'Ecole Centrale ainsi que du responsable du projet Education OpenOffice, Eric Bachard. En effet il participe de l'objectif de fond originellement établit l'année dernière: l'amélioration du module Impress d'openoffice en vue d'une utilisation pour Tablet PC. Chacun des projets s'accorde donc, avec le responsable Eric Bachard, sur une amélioration qui en constitue la particularité. Par contre le déroulement de chaque projet est similaire dans le sens où il convient de prendre en main OpenOffice ainsi qu'un certain nombre d'outils utilisés pour le développement de ce logiciel. Le passage de flambeau de projet à projet n'a pas été vraiment pris en considération jusqu'ici: le projet d'application de l'année dernière regroupant des membres du projet de groupe initial. Les nouveaux arrivants, c'est-à-dire le projet de groupe du début d'année et nous mêmes, se sont basés uniquement sur les rapports précédents et le blog tablet PC pour prendre connaissance du sujet et de la manière de le mener à bien. Ayant fait l'expérience de quelques problèmes durant ce projet qui n'ont pas étés étrangers aux groupes précédents nous pensons qu'il est important de préparer le prochain passage de flambeau pour qu'il puisse se faire dans de meilleures conditions. Aussi nous pensons qu'il convient de réellement prendre en compte ce fait que le travail que nous faisons, que les groupes précédents ont fait et que les groupes à venir ferons, fait partie d'un plus gros projet d'amélioration d'impress pour tablet PC évoqué plus haut. Nous pensons que ceci est possible par une appropriation plus marquée d'un espace commun consacré à ce projet: la partie du wiki Education qui y est consacrée. Plus concrètement nous voudrions aborder les points suivants qui, à nos yeux, constituent les clefs de la réussite et de la pérennité du projet Tablet PC / Education OpenOffice: la préparation aux méthodes de travail propres à ce projet la centralisation des liens et ressources sur le wiki la centralisation des pistes d'améliorations d'impress la forme particulière du rapport de ce projet.vi.1 La préparation aux méthodes de travail propres à ce sujet OpenOffice est un logiciel libre et présente à ce titre un certain nombre de caractéristiques. La communication se fait exclusivement sur le canal IRC et le responsable de projet dispose d'un emploi à plein temps sans relation avec OpenOffice. Il participe à titre bénévole à ce projet, il est donc probable qu'il ne sera pas disponibles pendant des horaires de bureau. La seule personne qui

21 travaille à plein temps sur Impress est Thorsten, il ne participe pas au projet Education mais est néanmoins disposé à aider et ses conseils sont précieux. Pour pouvoir communiquer, il faut donc être disponible. OpenOffice est un gros projet, s'aventurer dans le code est donc une aventure complexe et demande de l'investissement et une certaine dose d'indépendance. A bon entendeur....vi.2 La centralisation des liens et des ressources sur le wiki Il nous semble important de partager les ressources au sein du projet. En effet il faut parfois fouiller les wikis ou les sites pour répondre à des questions auxquelles seront confrontés tous les groupes. Nous voulons changer cela en centralisant sur la page wiki dédiée au projet ECN/Tablet PC l'ensemble des ressources et liens nécessaires au déroulement du projet. Le projet porte sur seulement un module d'openoffice, Impress, et souvent, on peut raisonnablement le penser, sur les annotations, c'est-à-dire sur une partie du code relativement réduite. Il serait donc intéressant de cumuler et de centraliser des connaissances sur cette partie-là du code, de faire en sorte que cette page wiki reflète le travail déjà accompli en capitalisant les connaissances nécessaires aux projets précédents. Ceci permettrait une vraie référence pour les nouveaux arrivants. Le fait que chaque projet s'ajoute au précédent dans la poursuite d'une meilleure adaptation d'impress aux Tablet Pc serait de cette manière mieux mis en évidence, chaque groupe pouvant visualiser son apport sur la page wiki dans une optique d'amélioration continue. Le nombre de rapports (4 rapports précédents pour notre groupe) sans même parler des historique de logs (conversations sur IRC) rend difficile une réelle mise en perspective du projet et nous pensons que ce travail de centralisation sur la page wiki per mettra de s'affranchir de la dépendance aux anciens rapports (ces derniers deviendraient alors intéressant pour l'amélioration qu'ils ont apportée)..vi.3 La centralisation des pistes d'amélioration d'impress L'amélioration à développer durant le projet constitue toute sa particularité, nous l'avons déjà expliqué. Lors de la recherche d'améliorations, les améliorations imaginées mais non développées sont oubliées. Nous proposons de créer une partie sur le wiki consacrée aux pistes d'améliorations d'impress. Non content de diriger les nouveaux groupes, cela permet aussi de faciliter la communication avec le projet Education. Nous pensions aussi conserver à la fois les pistes retenues (To do) mais aussi les pistes rejetées contenant une justification du rejet mais encore une fois aiguiller les nouveaux arrivants, faciliter leur arrivée sur le projet..vi.4 La forme particulière du rapport Le contexte de ces différents projets est le même, il est donc absurde de le réécrire pour chaque nouveau rapport. De plus les différentes erreurs rencontrées lors du projet (erreurs de compilations) sont déjà documentées sur le wiki, il paraît donc aussi inutile de les exposer dans un rapport alors qu'il serait plus pratique pour tous qu'elles soient retranscrites dans le wiki. Nous proposons, de manière à satisfaire aux exigences de l'ecole concernant les rapports de projets, de mettre sur le wiki un contexte type qui serait simplement collé dans le rapport rendu aux