Improvement of annotation functionalities in OpenOffice.org for effective integration into the code - Final report Nelle Varoquaux Léo Collet Rémy Dumas Christian Jacques Jonathan Winandy December 16, 2009

Contents 1 Presentation 1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 2 2

2 Project requirements 2.1 Specifications . . . . . . . . . . . . . . . 2.1.1 Objectives . . . . . . . . . . . . . 2.1.2 Products . . . . . . . . . . . . . 2.1.3 Product functionnalities . . . . . 2.1.4 Product approval criteria . . . . 2.2 Project progress . . . . . . . . . . . . . 2.2.1 Deliveries, time management and

. . . . . . .

4 4 4 4 4 4 5 5

. . . . . . . . . . .

6 6 6 7 11 13 15 16 16 17 19 19

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . schedule

3 Project contents and achievements 3.1 Technical aspects . . . . . . . . . . . . . . . . 3.1.1 Setting up a development environment 3.1.2 Architecture and Design . . . . . . . . 3.1.3 Debugging the code . . . . . . . . . . 3.1.4 Implementing the new functionalities . 3.2 Code protection . . . . . . . . . . . . . . . . . 3.3 User Interface . . . . . . . . . . . . . . . . . . 3.3.1 Presentation . . . . . . . . . . . . . . 3.3.2 Prototype design and development . . 3.3.3 Bottom right menu . . . . . . . . . . . 3.3.4 Hotkeys . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

4 Weekly description

20

5 Conclusion and perspectives

22

Appendices

23

A Environment setting A.1 Mercurial setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 OpenOffice.org setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24 24 24

B Bottom right menu suggestion

26 1

Chapter 1

Presentation 1.1

Context

The competition "HP Tablets PC" was obtained by a competition with educational non profitmaking purpose organized by HP on the subject: " the use of Tablet PC in the education ". The bone of Tablets PC is at present under Vista but we tried to set up a base of environment under freeware which is useful for the teachers and the pupils, these last ones being the main addressees. The objective is not to remain dependent on Windows. This research was moreover one of hurt developed by the teachers to win the competition. Last year’s project of group thus aimed at setting up in a most transparent possible way, the passage of Windows Vista in the most compatible possible free bone, while insuring the maximum of features under this one, so that the users can meet themselves there. 4 Our work aimed at prolonging this work by: • reading their reports; • correcting the last of their bugs; • implementing new relevant functionalities in OpenOffice Impress in prolongation of their work. Useful acquired knowledge for the continuation of the project We learned to handle the code of modules around OpenOffice Impress as well as C++, what was not intuitive because we were more developers been used to Java (Popular waltz). We learnt with Thorsten Behrens the standards of coding in term of notations and legibility of OpenOffice as well as rudiments on the conventions of naming C++. And we finally learnt to communicate in a simple and fluid way with the developers of OpenOffice in English, via the channel education.openoffice.org on irc.freenode.net.

1.2

Organization

The work was divided the following way: • Nelle was Project Manager and more specifically supervised the Use Interface design. • Jonathan was Responsible for the technical aspect. 2

• Christian was C++ developer. • Léo and Rémy were responsible for the communication (blogpost and reports writing, interview of external experts of OpenOffice.org) and designed the User Interface. The project lasted 2 months and a half. Typical week of work: • meeting with Morgan Magnin on Wednesday during an hour; • work weeting on Friday afternoon during 4 hours on an IRC chat with Eric Bachard.

3

Chapter 2

Project requirements 2.1 2.1.1

Specifications Objectives

The project consists in normalizing both The Eraser and The Saving Machine code, in order to have it integrated into OpenOffice.org code.

2.1.2

Products

• OpenOffice.org patch, containing our contribution; • documentation on the project (setup, project progress, code documentation); • weekly article on the evolution of the project, on Tablets PCs à Centrale Nantes blog.

2.1.3

Product functionnalities

• improving canvas management (intermediate zone on which it is possible to draw or annotate, etc while displaying a slide) and improving annotation visibility [30h]; • defining and development of an adequate menu for canvas changes, based upon a previous needs study on that topic (analyzing for example what exists in similar software and interactive whiteboard software [30h]; • correcting of pen and eraser width management, and the ink mode exit [20h + 10h]; • adding a popup dialog box to ask the user whether he wants to save his annotations when going out of the ’Diaporama’ mode [30h];

2.1.4

Product approval criteria

The code must be ’OpenOffice.org normalized’, compile correctly, be documented and tested. Each member of the project group should work at least 60 hours.

4

2.2 2.2.1

Project progress Deliveries, time management and schedule

Intermediate deliveries Weekly reports on Tablets PCs à Centrale Nantes blog, and an evolutive report delivered every other Monday. Final deliveries Final report, patch for OpenOffice.org. Resources Environments Technologies that are within OpenOffice.org. Human Resources Five enginnering students in 5th year at ECN: • Nelle Varoquaux; • Léo Collet; • Rémy Dumas; • Christian Jacques; • Jonathan Winandy. Technical resources • 2 Tablet PCs; • OpenOffice.org source code; • 1 Tablet PC with The Eraser and The Saving Machine code.

5

Chapter 3

Project contents and achievements 3.1 3.1.1

Technical aspects Setting up a development environment

Our first difficulty was to set up a development environment1 . Between March 2009 and October 2009, the project had to switch from SVN to Mercurial. None of us had previously used Mercurial before, and we had several difficulties, first cloning the code, then compiling. Mercurial is very similar to SVN, so we didn’t have many problems getting used to it. Cloning the code took us about 1 hour (12,4 Gb, and more of 200 000 items to download). Compiling was another problem. The two computers we were using were working on Ubuntu, one on Jaunty, and the other one on Karmic. On the Jaunty computer, we just followed the OpenOffice.org tutorial2 . When we tried to run the configure script, we faced several errors. By studying them, we were able to install most of the missing packages. Once the configure ran properly, the build happened without any error! On the Karmic computer, after doing exactly the same thing, the configure script ran properly, but the build failed. It took Nelle a few extra hours to have it compile. Since we had so many difficulties, we wrote down a tutorial3 , detailing all the extra packages we installed compared to the one listed on the OpenOffice’s wiki, for the next team. Of course, this list of package is incomplete (we tried to apply it on another computer on Jaunty, and the build didn’t work). Once the first build was complete, we could shorten the time spent compiling, by building only the module that had been changed. Once again, the documentation we found was incomplete and hard to apply. 1 Additional

information can be found at appendix A

2 http://wiki.services.openoffice.org/wiki/Ubuntu\_Build\_Instructions 3 See

A.2

6

Figure 3.1: OpenOffice annotation structure

3.1.2

Architecture and Design

OpenOffice’s code is organized in modules. Thanks to PGROU-2008’s report, we immediately knew only two modules interested us, the slideshow module, and the sd module, containing the User Interface4 . Sketch 3.1, from [3], allows to understand how OpenOffice works from the User Interface to spread all the modifications.

Inside the sd module The sd module contains all the code concerning the implementation of the contextual menu. If we go through the path sd/source/ui/slideshow, we can observe different types of file. localize.sdf sd source\ui\slideshow\slideshow.src RID_SLIDESHOW_CONTEXTMENU CM_ENDSHOW sd source\ui\slideshow\slideshow.src RID_SLIDESHOW_CONTEXTMENU CM_ENDSHOW

0 menuitem 0 ar 2002-02-02 02:02:02 0 menuitem 13691 as-IN 2002-02-02 02:02:02

This file contains all the internationnalization of the text contained in the menu. This part is only modified by Sun developers. slideshow.src Contains the skeleton of the menu. Each item of the menu is written, in the order it should appear. Each one has an identifier. 4 Herein

referred as UI

7

Menu RID_SLIDESHOW_CONTEXTMENU { ItemList = { MenuItem { Identifier = CM_NEXT_SLIDE ; Text [ en-US ] = " Next" ; }; MenuItem { Identifier = CM_PREV_SLIDE ; Text [ en-US ] = " Previous" ; }; MenuItem { Identifier = CM_GOTO; Text [ en-US ] = " Go to Slide" ; There are different possible types of element: a link, a submenu, a separator etc... Menu, submenu and links must have and identifier. This identifier must be declared in the header of this file, slideshow.hrc. ]define CM_PREV_SLIDE 1 ]define CM_NEXT_SLIDE 2 ]define CM_GOTO 3 To each identifier is associatied a number, which needs to be unique. slideshowimpl.cxx and slideshowimpl.hxx This file is used to enable or disable items, and to add checkbox to them in the menu. This way, you can disable an action that has no sens of being in the menu:

pMenu->EnableItem( CM_NEXT_SLIDE, ( mpSlideController->getNextSlideIndex() != -1 ) ); pMenu->EnableItem( CM_PREV_SLIDE, ( mpSlideController->getPreviousSlideIndex() != -1 ) || (eMode == SHOWWINDOWMODE_END) || (eMode == SHOWWINDOWMODE_PAUSE) || (eMode == SHOWWINDOWMODE_BLANK) ); For example, the menuItem CM_NEXT_SLIDE, corresponding to the link "Next", is visible only if there is a slide after the one we are currently on. In this file are also all the actions that follow the selection of one action. It can be a hover on a link to a submenu, a click on a link to an action, or key pressed. Depending on the identifier, it will call a method, in this same class:

8

case CM_PREV_SLIDE: gotoPreviousSlide(); mbWasPaused = false; break; case CM_NEXT_SLIDE: gotoNextSlide(); mbWasPaused = false; break; For example, in case the menuItem with the CM_PREV_SLIDE identifier has been selected, the method gotoPreviousSlide() is called. Sometimes, the action calls a method of a class in another module. For example, a method setUsePen( sal_Bool bMouseAsPen), depending on the values of the (attribute) will launch several actions in the module Slideshow. Indeed, this method deals with the color and the width of the pen.

Any aValueWidth; if( maPresSettings.mbMouseAsPen ) aValueWidth «= mdUserPaintStrokeWidth; beans::PropertyValue aPenPropWidth; aPenPropWidth.Name = OUString( RTL_CONSTASCII_USTRINGPARAM( "UserPaintStrokeWidth" )); aPenPropWidth.Value = aValueWidth; mxShow->setProperty( aPenPropWidth ); Any aValueEraseAllInk; if( maPresSettings.mbMouseAsPen ) aValueEraseAllInk «= mbEraseAllInk; beans::PropertyValue aPenPropEraseAllInk; aPenPropEraseAllInk.Name = OUString( RTL_CONSTASCII_USTRINGPARAM( "EraseAllInk" )); aPenPropEraseAllInk.Value = aValueEraseAllInk; mxShow->setProperty( aPenPropEraseAllInk ); This extract of setUsePen calls the method setProperty5 . The Slideshow module In sd/source/engine, the class slideshowimpl.cxx allows to statically and dynamically show a presentation. This class also relies on user interaction, the interface providing means to register some UI event listener. This class realizes the interface between the previous sd module slideshowimpl class. We can indeed find the method setProperty, mentioned before. The method setProperty is merely an interface between UI and the eventmultiplexer. We indeed can observe links between 5 Several bugs were introduced in the project The Eraser, in this method. Indeed, setUsePen calls ALL the method displayed here. If mbEraseAllInk was set to true, it will apply the method EraseAllInk, and do the action. Therefore, if the boolean mbEraseAllInk is not set to false again, the next time setUsePen is called, the method EraseAllInk will be called again.

9

the two classes:

if (rProperty.Name.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM("EraseAllInk") )) { bool nEraseAllInk(false); if (rProperty.Value »= nEraseAllInk) { OSL_ENSURE( mbMouseVisible, "setProperty(): User paint overrides invisible mouse" ); // enable user paint maEraseAllInk.reset( nEraseAllInk ); maEventMultiplexer.notifyEraseAllInk( *maEraseAllInk ); } else { // disable user paint maEraseAllInk.reset(); maEventMultiplexer.notifyUserPaintDisabled(); } if( mnCurrentCursor == awt::SystemPointer::ARROW ) resetCursor(); return true; } The header of this class is not in the same folder. It can be found in slideshow/source/inc/userpainteventhandler.hxx. The eventmultiplexer class listens to the XslideShowView and fires events registered for certain user actions. Other state changes (start and end of slide) are handled in this class as well. Therefore, the actions of the menu called by the user are registered here. For example, for the action «Erase All Ink on Slide»:

bool EventMultiplexer::notifyEraseAllInk( bool const& rEraseAllInk ) { return mpImpl->maUserPaintEventHandlers.applyAll( boost::bind(&UserPaintEventHandler::eraseAllInkChanged, _1, boost::cref(rEraseAllInk))); } Once again, the header is not in the same folder, but in sd/source/inc/eventmultiplexer.hxx. The last class we will be looking at is the userPaintOverlay. This class registers itself at the EventMultiplexer, listening for mouse clicks and moves. Therefore, when the mouse is dragged, an annotation is drawn, or erased, depending which mode is activated. We can find in this class 10

most of the methods concerning the annotation drawing and erasing. We will not detail more the methods of this class, since a plain code review is sufficient to understand most of the concept of the class.

3.1.3

Debugging the code

At the beginning of the project, we observed some bugs in the code. Some where solved by Eric Bachard, in the first patch he sent us, and others by the team: 1. actions not taken in account in the menu; 2. eraser width bug. Actions not taken in account in the menu This bug was the hardest we were confronted at. We didn’t know at all where its origin could be located, and what could generate such a bug. Doing a code review, and testing more thoroughly the annotation in Impress, we noticed a few things: • When we tried to change the Eraser Size, or the Pen Color the Pen Size, it didn’t seem to be taken in account. We couldn’t write anymore. • But when we clicked on «Erase All Ink On Slide», the Ink was erased. We couldn’t write anymore. • When we clicked on Pen Color, Eraser Size or Pen Size twice, we action seemed to be taken in account AND we could write (but not erase). • When we drew Ink, and we clicked on «Erase All Ink On Slide», it erased all the Ink. By clicking once on the action «Eraser Size», we switched back to the Pen Mode. We could write again. By clicking on any action concerning the annotations, all the Ink on slide was erased again. The action «Erase All Ink on Slide» had just been activated again. We first did a code review of the userPaintOverlay class. The change of the Eraser width seemed a bit strange: bool eraseInkChanged( sal_Int32 rEraseInkSize ) { if(this->mbIsEraseModeActivated) { this->mbIsEraseModeActivated=false; } else { this->mbIsEraseModeActivated=true; this->mnSize=rEraseInkSize; return true; } Changing the Eraser size would also switch from Pen to Eraser and vice versa. It didn’t seem to be a good workflow... After a long code review, we noticed the problem came from the method setUsePen in the sd module. Indeed, all the following actions would be executed in this order: 11

1. change pen color; 2. change pen size; 3. erase all ink on slide, passing the boolean mbEraseAllInk; 4. EraseInk, which corresponds to the change of the Eraser size (and the switch from eraser mode to pen mode and vice versa). This explained why the menu seemed to behave very strangely. Therefore, while implementing the switch from the Pen Mode to the Eraser Mode and vice versa, we started to implement a new method, setUseEraser. To distinguish setUsePen and setUseEraser, we chose to separate the action of the menu in two types: • setUsePen would handle all the actions that would end by the Pen Mode being activated: – change pen color; – change pen size; – erase all ink on Slide; – and the future Switch to Pen Mode. • SetUseEraser would handle all the actions that would end by the Eraser Mode being activated: – change the Eraser size; – and the future Switch to Eraser Mode. Eraser width bug At one point in the project, we noticed the Eraser mode that we thought didn’t work did work. Indeed, the Eraser was so small (1 pixel large) and the refreshing problem made the erased parts so small that we didn’t see them. Once we had spotted that the mode was activated, we started to look whether the size was set correctly. First, we had a look at the handleMouseDragged method, of the userPaintOverlayClass. We could observe mnSize is the size of the mouse. Before starting to do a code review, we started by doing a very simple test. In the following method, we replaced mnSize by 200. This way, if our theory was right, and the eraser worked, we would be able to see it.

12

virtual bool handleMouseDragged( const awt::MouseEvent& e ) { if(mbIsEraseModeActivated) { //define the last point as an object //we suppose that there’s no way this point could be valid ::basegfx::B2DPolygon aPoly; maLastPoint.setX( e.X-mnSize ); maLastPoint.setY( e.Y-mnSize ); aPoly.append( maLastPoint ); maLastPoint.setX( e.X-mnSize ); maLastPoint.setY( e.Y+mnSize ); } Once we compiled, we could observe the eraser did work. We then did a simple code review, by going through all the code, we spotted that, at one point, the sal_int32 mnSize of the Eraser had been replaced by a boolean.

3.1.4

Implementing the new functionalities

Specifications We wanted to implement a new functionality that would appear in the menu, enabling switching from the Ink mode to the Pen mode. • The Ink mode: this mode would allow the user to write on top of the existing slide. This mode already exist in Impress. • The Eraser mode: this mode would allow the user to erase Ink. As seen in part 3.3, we thought about implementing other modes than the two described below: • The highlighter mode: this mode would allow the user to write under the existing slide, or by transparency. • The Mouse mode: this mode would disable all the previous mode. The user would be able to use the pointer as a normal mouse. We had to take in account that those modes could be also implemented in our design. In the UserPaintOverlay class... By observing the methods of this class, it seemed obvious that a boolean variable, mbIsEraserModeActivated, handled the switch from the Ink mode to the Erase mode. We chose to code two methods: • switchEraserMode() that would assign true to this variable; • switchPenMode() that would assign false to this same variable. And of course, we had to make sure the right mode was enabled when it should be. For example, as mentioned before, the action «Erase All Ink on Slide» would erase all the ink on the slide. Therefore, it didn’t make much sense to leave the pointer in the Eraser Mode option. 13

The User Interface Implementing it in the menu was slightly more difficult. First we had to add the links in the menu. We were able to do this thanks to the file slideshow.hrc, by adding two more constants: CM_ERASE_MODE and CM_PEN_MODE, and linking these two constants with the translation (We chose «Pen Mode» and «Eraser Mode»). In the file slideshowimpl.cxx, we had to complete the different methods. We added mbPenMode and mbEraserMode to indicate whether we are in pen mode or eraser mode6 . We also had to check these variables were set correctly when doing any action that would change the pointer mode.

6 We

need to factor this code, and replace these two variables needs to merge them into one and unique variable. This variable should be an integer, so that it can add more different modes.

14

3.2

Code protection

Our goal was to develop functionalities in Impress, the slideshow presentation program. It was very important to protect our code in order to allow a compilation without compiling our functionalities. These protections give us the possibility to create versions without Tablet PC options and the annotations in a presentation and to deliver a repository with our changes, even if there is problem in our code and our work is not complete. We had to insert a variable which will be read during the compilation to skip some lines. Thanks to Mercurial, it’s easy to show all the changes that appeared in the code. The variable ENABLE_PRESENTER_EXTRA_UI is set when we configure the compilation with the command ./configure - -enable-presenter-extra-ui Example with the protection in file slideshow/source/engine/slide/userpaintoverlay.hxx: ] ifdef ENABLE_PRESENTER_EXTRA_UI PolyPolygonVector getPolygons(); void drawPolygons(); ] endif Although it was quite easy to understand this point, the realization took a very long time. We had to care about the variables between the tags: we got a lot of error during compilation because the tags were not in the right places and hid several variable declarations which were called by functions. Once all tags were correctly written, we had some mistakes during compilation: even if the variable ENABLE_PRESENTER_EXTRA_UI was set to YES, the lines were not read and compiled or inversely. There were problems with the makefile in the different modules. So we had to add the command to compile with this variable7 : .IF "$(ENABLE_PRESENTER_EXTRA_UI)"=="YES" CDEFS+= -DENABLE_PRESENTER_EXTRA_UI .ENDIF Conclusion Protecting our code was important and mandatory to deliver a clean repository. The time to do this point was very difficult to estimate and took us much more than we first scheduled

7 Example

taken from file slideshow/inc/makefile.mk.

15

Figure 3.2: Previous OpenOffice Impress contextual menu

3.3

User Interface

3.3.1

Presentation

We worked as described below: 1. detailed study of the existing interfaces in similar software (eg. Impress, Beamer, PowerPoint); 2. prototype design, based upon the previous study and our personal contributions; 3. prototype formalization (drawing); 4. prototype validation; 5. implementation in the code. We discovered what was the contextual menu in OpenOffice Impress (see figure 3.2). After our first use of the different functionalities of the project, we noticed several points: • The functionnalities are accessible through a menu. We need to click right to access this menu. By studying Beamer and PowerPoint, we thought of implementing an icon based visual menu, on the bottom right of the slides, semi transparents. • After using the "Erase all ink", we couldn’t use the pen anymore. • The "erase mode ON/OFF" didn’t make much sense. We didn’t see anything happen8 . • The menu needs to be reorganized. • There is no feedback on which mode we are in (Eraser or Pen ?). More information about OOo UIs are available at [5]. 8 There

was no action behind the link.

16

Figure 3.3: Prototype 1

Figure 3.4: Prototype 2

3.3.2

Prototype design and development

First prototype (see picture 3.3) Comments Few changes with regard to the original menu. Advantages • a new functionality “save ink” which allow to save notes when the user leaves the diaporama mode; • relevant options are grouped together (eraser size and pointer options). Disadvantages • the term “save ink” isn’t clear : we have to find a better expression; • it would be logical to group together the “eraser size” and “pen width” modes into a single “width” mode.

17

Figure 3.5: Prototype 3

Figure 3.6: Prototype 4

Second prototype (see picture 3.4) Comments The general idea consists in grouping together all the options relative to the pointer in one single menu “pointer options”. The following prototypes are designed as an improvement of this one. Advantage

Better legibility of the menu.

Disadvantage Imbalance between the size of the “pointer options” menu and the global menu. Third prototype (see picture 3.5) Comments Difference with the second prototype: the ’eraser size’ and the ’pen size’ options disappear for a single menu ’width’. Fourth prototype (see picture 3.6) Comments • thematic organisation of the options; • the “save ink” menu disappear from the ’pointer options’.

18

Figure 3.7: Menu suggestion

Advantages • improvement of the second model by creating a new single menu ’width’ (as in Prototype 3); • lowering of the global menu. Disadvantage A lot of changes to implement.

3.3.3

Bottom right menu

We thought about integrating a bottom right menu, such as in some similar software. An example of our work is illustrated by figure 3.7 and the complete workflow can be found in appendix B.

3.3.4

Hotkeys

I could be useful, as a project perspective, to think about implementing hotkeys. This could allow the user to choose whether he uses the right-click menu or his keyboard to access the different functionalities.

19

Chapter 4

Weekly description

20

Week 1

2

3

4

5

6

7

8

9

Nelle Tool installation (communication and organization) Help given to Christian to compile his version. Began to try to compile on her own PC.

Christian OS setting.

Léo & Rémy Scheduled existing UIs study strategy.

Successful compilation.

Compilation report. Tool preparation. Start ed working on Mercurial. Compilation documentation. Activities schedule. Requirements for effective integration. Weekly IRC meetings organization.

Started working on Mercurial.

Failed at trying to contact with Pr. N. Moes to see how his whiteboard interactive tool works. Got relevant information on using OOo on tablets PCs.

Studied how to implement the menu. Successfully compiled Eric Bachard’s patch. Major improvements on UI review and development. UI implementation after finalizing prototypes. UI debug. Wrote part of the final report. Elaborated D-day presentation.

Began writing protection.

Continued studying OOo UI.

HG study and synchro. Code protection.

Finished tion.

protec-

Wrote part of the final report.

Began working on the UI possible improvements and existing functions. Wrote a 6 page report on Impress UI. Studied how other software manage their UI. Major improvements on UI review and development. Prototype design.

Wrote part of the final report. Composed and formalized the final report. Elaborated D-day presentation.

Figure 4.1: Weekly report summary

21

Jonathan Tool installation (communication and organization) Successful compilation. Some bugs reported.

Chapter 5

Conclusion and perspectives This project was very interesting and intense. For the first time of our scholarity, we worked on a very big, important and professional project. This one allowed us to see a glance of how OpenOffice developpers worked, their challenge and problematics, not only du to the complexity of the code, but also as an internationnal and opensource community. Indeed, people from all other the world work on this project, from computer science pros to other students like us. The difference of level between the developpers, and the broad community induce strict imperatives of quality assurance and lisibility. This project also allowed some of the members of the group to discover other part of computer science than coding, with the User Interface. Unfortunately, we didn’t have the time to implement all the features that where suggested by the UI team. Indeed, the project was in worst shape than expected when we took over the code. Among the things that could be improved: • implementing the bottom right menu; • implementing visual feedback differencing the Pen mode and Eraser mode, by changing the cursor to a pen or an eraser; • implementing the two extra features suggested by the UI team; – highlighter mode; – mouse mode. • implementing the prototype chosen: regrouping the functionnalities of the cursor option in a submenu; • improving the ink saving; – saving the changes due to the eraser; – solving the numerous bug due to the ink saving; – implementing the pop-up window to ask whether if the user wants to save or not the ink. • and finally, solving the submenu bug, which appeared to be very strange. Indeed, this bug appears only on Linux, and could probably solved by looking at the code of the module vlc, that hasn’t been modified in months. We are very thankful to Eric Bachard and Thorsten Behrens for their help. 22

Appendices

23

Appendix A

Environment setting A.1

Mercurial setup [1]

On Linux $ sudo apt-get install mercurial In order to download the source code:

$ hg clone http://hg.services.openoffice.org/hg/cws/eraser01

A.2

OpenOffice.org setup [4]

Some additional packages are required:

$ apt-get install g++ gcc bison flex libarchive-zip-perl libcups2-dev libpam0g-dev subversion sun-java6-jdk gperf libfreetype6-dev libxaw7-dev libfontconfig1-dev libxrandr-dev patch libgconf2-dev libgnomevfs2-dev ant python-dev libgtk2.0-dev ccache libgraphite-dev It could also be useful and required to install: • tcsh • autoconf • libwpd-dev • libxslt-dev • libdb4.7-dev • libneon27-dev • libhunspell-dev • libaltlinuxhyph-dev

24

• dmake • libxercers2-java-gcj • libjaxp1.3-java-gcj • libcurl4-gnutls-dev If it is still impossible to have it compile, the following inelegant but efficient method should work: $ sudo apt-get build-dep openoffice.org Compilation procedure Do not worry if compilation takes about 7 or 8 hours! $ autoconf -i $ ./configure -help $ ./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 -disable-build-mozilla -disable-odk -with-system-python $ ./boostrap $ source LinuxX86Env.Set.sh $ dmake Installation Any older version of OOo will be replaced by the one you are installing. A method, provided in [2], but not tested, avoids the problem.

• Go to /instsetoo_native/unxlngi6.pro/OpenOffice/deb/install/en-US • Execute $ sudo dpkg -i *.deb In order to add functionalities to the Application menu: $ cd desktop-integration $ sudo dpkg -i *.deb If an older version is installed yet, a conflict could happen. Package openoffice.org-core should be removed. If the user wishes to keep the existing menus, deb package from desktop-integration folder can not be installed. The file can be found at /opt/OpenOffice.3 form where launchers can be created if necessary.

25

Appendix B

Bottom right menu suggestion

26

Figure B.1: Bottom right menu workflow

27

Bibliography [1] Mercurial. Learning mercurial in workflows. [2] OOoForum.org. Is it possible to run multiple versions of oo? [3] Aude Quintana and Olivier Girardot. Rapport final du projet d’application "the eraser", 2008. [4] OpenOffice.org wiki. Building on linux. [5] OpenOffice.org wiki. Graphical user interfaces.

28