Education Project/Effort/Various adaptations on Sugar/Work In Progress

From Apache OpenOffice Wiki
Jump to: navigation, search

Work on OOo/OOo4Kids

Building OOo

Building OOo4Kids on Sugar

Distribution: Sugar on a Stick "Strawberry"

Required packages: yum install gcc gcc-c++ bison flex patch freetype-devel libX11-devel libXaw-devel libXrandr-devel perl-Archive-Zip make pam-devel gperf GConf2-devel python-devel curl-devel

gtk is also required, unfortunately Strawberry crashed each time I tried to install the package, therefore this preliminary build will be done using --disable-gtk

Current state: done, see http://ooo4kids-xo.blogspot.com/

Twarz 12:21, 17 August 2009 (UTC)

Building OOo4Kids on Ubuntu9.04

I tried building OOo4Kids on a more recent computer than the first time. Compiling OOo was okay, but when I apply the patch for OOo4Kids, run the configure / bootstrap / everything, the compilation will always send this error line: "dmake: /home/twarz/OOo/OpenOfficeSrc/DEV300_m52/solenv/inc/unxlngx6.mk: line 142: Error: -- Expecting macro or rule defn, found neither"

I'm still trying to fix this issue, but I'm a bit at a loss of words: I even tried to copy/paste the solenv directory from the working OOo4Kids build and it still doesn't work.

Edit: in the solenv/inc/unxlngx6.mk, starting from line 139: comment the ".IF... .ENDIF", and add the modules that were in the ".ELSE" just before the comments. Compilation for OOo4Kids then goes normaly for some time before encountering some new errors.

Edit: build is now fonctionnal. Here is the list of what has been modified:

-File framework/source/services/backingwindow.cxx wasn't compiling because of undeclared variables. Said variables were located in conditions depending specifically on a build of OOo4Kids or OOo. Solution: commenting the problematic lines. WARNING: to be used only for the compilation of OOo4Kids. Things might go wrong if you try to build OOo with those comments...

Precise location of the comments: line 305, 309, 459, 462.

-File svx/source/cui/treeopt.cxx : same problem as above.

Precise location of the comments : line 2166.

-File scp2/source/calc/calc_module.scp :

Starting from line 95 should be:

 #ifndef OOo4Kids
 gid_File_Res_Analysis,
 #endif

Line 44:

 .IF "$(OOo4Kids)"=="YES"
 SCPDEFS+=-DOOo4Kids
 .ENDIF


-File scp2/source/math/makefile.mk

Just add:

 .IF "$(OOo4Kids)"=="YES"
 SCPDEFS+=-DOOo4Kids
 .ENDIF

Build at least fonctionnal. :)

Starting from DEV300_m54, all previous modifications are not needed anymore.

The build on Linux is also compatible with ReiserFS.

Twarz 12:36, 17 August 2009 (UTC)

Building on Windows Vista

OOo4Kids...

Building OOo4Kids on Windows Vista is not that hard, but there is still some trouble to go through this process. Actually, until using CPAN on Cygwin. Until then, this is going smoothly but i had some trouble installing Archive::Zip and URI modules, after many unsucsessful try, it worked suddenly: i just made a reboot. Then applying the patch, the configure and all the other things went smoothly till the build. I tried on different version of OOo4Kids and even on OOo and there is still the same building problem that i don't know how to go through:

echos: Command not found. d:/OOo4Kids/DEV300_m52/solver/300/wntnsci12.pro/bin: Permission denied. dmake: Error code 1, while making '../wntmsci12.pro/obj/wrap_hidclex.obj' dmake: '../wntmsci12.pro/obj/wrap_hidclex.obj' removed. runnid processes: 0

3 module(s): hsqldb stax soltools need(s) to be rebuilt

Reasons:

ERROR: error 65280 occured while making /cygdrive/d/OOo4Kids/DEV300_m52/stax ERROR: error 65280 occured while making /cygdrive/d/OOo4Kids/DEV300_m52/soltools/support ERROR: error 65280 occured while making /cygdrive/d/OOo4Kids/DEV300_m52/soltools/HIDCompiler ERROR: error 65280 occured while making /cygdrive/d/OOo4Kids/DEV300_m52/hsqld

I'm still trying to go through this.

"""""""""""""""""

I think I already read something about that. Are there space in the paths, or did you really keep the filetype set to “Unix/binary” ? (that's a cygwin option)

IMHO, the answer is given at Building on Windows

Ericb 13:28, 2 August 2009 (UTC)

...with debugging symbols

Using: DEV300_m55 version

In a first time, i have built this version from scrath following this wikipage. This went smoothly, without any problem. When the build was complete, I went in the directory instsetoo_native/wntmsci12.pro/OOo4Kids/msi/install/fr and installed it via explorer. I made some tests and then wanted to try it with Visual Studio Debugger, and here are the problems.

Once at this point, i tried to use it without using the symbols, but that was a bad idea since VS didn't have the source of OOo4Kids so debuggging with it was useless. I imported the sources without more results, then Eric and Twarz told me about building with the symbols. When doing this, i went into a problem with the sw/source/core/doc/dbgoutsw.cxx line 996 as dbg_out is defined at some other place (same error once this one is fixed line 1024) and i commented it, but that might not be a solution as there is problems with symbols after that.

And so there are problems with the build with symbols as in sw/wntmsci12.pro/lib there is nothing as big as 700 or 800MO but 2.5MO for the biggest one.

belabb_a 12:01, 26 August 2009 (UTC)

After an other build on DEV300_m56, i tried to build the desktop module with symbols as i found that if you launch Writer or other applications without using soffice, it will crash instantly. So i built without real problems and then i looked for special dll files that could help me (as new build libraries) but i found out from a search from google that symbols are in another file with the extension .pdb (program debugger). Then, i tried to load them to visual studio without success. Then, i put the pdb files of the desktop module on the /OOo4Kids0.5/program/ directory and the symbols were loaded in Visual Studio. So i now have access to the source code while debugging to see what OOo4Kids is doing. I still have some problems like putting a real breakpoint or launching OOo4Kids from the debugger and not attaching the process but i'll do some research about that.

belabb_a 16:48, 02 September 2009 (UTC)

Debugging - Improving Performances

Writer crash: paragraph limit

How to reproduce

  • Open a Writer Document
  • Copy a full page of text, no space, no new line
  • Paste, paste, paste... Around page 14-15, the paste will brutally stop, unfinished.
  • Erase the last character, write a new one.

=> Crash

Where is the problem

file: sw/source/core/text/txtfrm.cxx

method: xub_StrLen SwTxtFrm::FindBrk(const XubString &, const xub_StrLen, const xub_StrLen) const

line: 665-666 :

       while( nFound <= nEndLine && ' ' != rTxt.GetChar( nFound ) )
               ++nFound;

What is exactly happening

This file contain two very similar "while"s :

       while( nFound <= nEndLine && ' ' == rTxt.GetChar( nFound ) )
                ++nFound;        
       while( nFound <= nEndLine && ' ' != rTxt.GetChar( nFound ) )
               ++nFound;

In every case, the first one goes on correctly. The second one, though, is the compromised one.When the crash is happening, nEndLine value is set to 65535. The program skips the first while and directly start processing the second one. nFound initial value is set to 65463. The while goes on until nFound reaches 65534... And suddenly see it's value reinitialised to 0. The problem seems to be located in the rTxt.GetChar method. When nFound reaches 65534 or 65535, this function seems to put back it's value to 0, therefore blocking the program in this "while" (0->65535->0->65535->...)

The function that needs attention is XubString::GetChar . If, of course, I didn't do anything wrong, which is still highly possible.

Twarz 11:22, 10 August 2009 (UTC)

How to solve the problem

This problem has been half solved. The crash indeed was caused by nFound who switched back to 0 once he reached 65535. A problem of type. Therefore, here is my proposition to start fixing the issue. Here is what the compromised function should look like:

 xub_StrLen SwTxtFrm::FindBrk( const XubString &rTxt,
                                                   const xub_StrLen nStart, const xub_StrLen nEnd ) const
 {
         unsigned int nFound1 = nStart;
         const unsigned int nEndLine = Min( nEnd, rTxt.Len() );
 
 	   while( nFound1 <= nEndLine && ' ' == rTxt.GetChar( nFound1 ) )
 		 ++nFound1;
 
 	   unsigned long int nFound2 = nFound1;
 
 	   while( nFound2 <= nEndLine && ' ' != rTxt.GetChar( nFound2 ) )
 		 ++nFound2;
 
	   return (xub_StrLen)nFound2;
 }


This does fix the crash: an unsigned int won't reset reaching 65535. But there is another problem: in the very same conditions where the crash would have occurred and these modifications have been added, the user is unable to write anything anymore. He is stuck at the point when the paste stopped. This problem seems quite unrelated, though, more researches will be needed to find the why of this problem. Well, It's half-solved, so it's still a little progress.

Twarz 15:15, 10 August 2009 (UTC)

Final patch on which Ericb agreed in order to correct the above crash:

 Index: sw/source/core/text/txtfrm.cxx                                                   
 ===================================================================
 --- sw/source/core/text/txtfrm.cxx      (revision 274676)                               
 +++ sw/source/core/text/txtfrm.cxx      (working copy)                                  
 @@ -651,8 +651,8 @@
  xub_StrLen SwTxtFrm::FindBrk( const XubString &rTxt,                                   
                                                   const xub_StrLen nStart, const xub_StrLen nEnd ) const                                                                       
  {                                                                                      
 -       xub_StrLen nFound = nStart;                                                     
 -       const xub_StrLen nEndLine = Min( nEnd, rTxt.Len() );                            
 +       unsigned long int nFound = nStart;                                                   
 +       const unsigned long int nEndLine = Min( nEnd, rTxt.Len() );                          
                                                                                         
         // Wir ueberlesen erst alle Blanks am Anfang der Zeile (vgl. Bug 2235).         
         while( nFound <= nEndLine && ' ' == rTxt.GetChar( nFound ) )                    
 @@ -665,7 +665,7 @@
         while( nFound <= nEndLine && ' ' != rTxt.GetChar( nFound ) )                    
                 ++nFound;                                                               
                                                                                         
 -       return nFound;                                                                  
 +       return (xub_StrLen)nFound;                                                      
  }                                                                                      
                                                                                         
  /************************************************************************* 

Twarz 20:04, 10 August 2009 (UTC)

The issue + patch have been submitted to IssueZilla on this page.

Impress: CPU overuse (presentation wizard)

How to reproduce

  • Open a new Impress document
  • In the wizard, select 'from template', then click next
  • click next
  • click next
  • Fill one of the boxes until it reaches the end (will work better with a large copy/paste: a pop-up window will tell you that you have reached the limit)
  • Click next

=> Huge loading time for the next page of the wizard, then huge loading time when working on the presentation itself, for any action concerning the first page.

It is not a natural bug (the odds of someone filling one of these boxes is actually pretty low), but the waiting time for the next step to be available is quite impressive.

Twarz 14:12, 17 August 2009 (UTC)


Did you search in the recent issues to be sure the issue is not known  ? (and maybe fixed ?)

Ericb 21:46, 17 August 2009 (UTC)


I searched and it seems like the issue has not been presented already. Update: on both OOo and OOo4Kids, once the presentation has started, any action intended on the first slide (containing the "name of the company" if you filled the first dialogue box) will cause huge slowdown and CPU overuse. Everything is fine on the other slides.

Twarz 13:01, 18 August 2009 (UTC)

Where is the problem

What is exactly happening

How to solve the problem

Possible correction to this problem could be to reduce the size of the textbox. It is now set à 65535 characters (beside this point, any copy/paste will be automatically truncated), which is waaaaay too much. No company has a name that long, and this indulge an incoherent behaviour because there is no way 65535 characters are going to fit on one slide.

One of the compromised file is vcl/source/control/edit.cxx, line 845, nMaxLen == 65535. A possible solution would be to reduce this number to a coherent value. It would indirectly fix many issues:

  • no more / less slowdown (and CPU overuse) which was caused by a too great number of characters
  • I would fit on the slide (it's useless to have only a fragment of what you wrote on your slide and the rest in empty space, wihch is currently what's happening)

But this file isn't the only one that has to be changed, indeed this one only take care of truncating any copy / paste that would go above the character limit. In ordder to properly and cleanly fix this issue with this idea, we have to locate every thing relevant and set correct values everywhere (in the case of simple writing and not copying/pasting, for instance).

Twarz 15:57, 18 August 2009 (UTC)

Impress: timer crash

How to reproduce

  • Erase your preferences.
  • Create a new presentation. Make sure the preview is enabled. Click next.
  • Select a transition effect between slides, whichever you want.
  • Click create at the end of the preview, but before the background turns gray again (basically, the background must be black and the preview must be over)

=> Crash.

Where is the problem

The problem seems to be located in vcl/source/gdi/bmpfast.cxx, line 105. Tracing results will come soon.

Twarz 15:57, 18 August 2009 (UTC)

What is exactly happening

Two major changes have been added to the sources to start correcting this crash, everyhting using gdb (documentation can be checked here). First patch applied:

 Index: slideshow/source/engine/eventmultiplexer.cxx
 ===================================================================
 --- slideshow/source/engine/eventmultiplexer.cxx	(revision 275030)
 +++ slideshow/source/engine/eventmultiplexer.cxx	(working copy)
 @@ -448,8 +448,9 @@
          for( UnoViewVector::const_iterator aIter( mrViewContainer.begin() ),
                   aEnd( mrViewContainer.end() ); aIter != aEnd; ++aIter ) 
          {
 -            ((*aIter)->getUnoView().get()->*pViewMethod)( mxListener.get() );
 -        }
 +	    if ( (*aIter)->getUnoView().get() )
 +    		((*aIter)->getUnoView().get()->*pViewMethod)( mxListener.get() );
 +	}
      }
  }

Why ? Because in this situation, getUnoView()->get() returned NULL, therefore provoking a Segmentation Fault (typical of situation when trying to retreive a variable from a NULL struct pointer). Verification of it's return value->crash corrected.

Or not. New problem, same situation:

 Index: vcl/source/window/window.cxx
 ===================================================================
 --- vcl/source/window/window.cxx	(revision 275032)
 +++ vcl/source/window/window.cxx	(working copy)
 @@ -6372,7 +6372,7 @@
  {
      DBG_CHKTHIS( Window, ImplDbgCheckWindow );
  
 -    if ( mpWindowImpl->mbVisible == bVisible )
 +    if ( mpWindowImpl && mpWindowImpl->mbVisible == bVisible )
          return;
  
      ImplDelData aDogTag( this );

Same thing as above: NULL pointer, trying to retreive a variable->segfault. Same solution: test if mpWindowImpl exists ( != NULL). If it does, go on normally and check the variable. If not, skip the condition and continue.

Now the presentation is launched correctly, and seems to work fine. Unfortunately, there is another problem, always while following the same how-to-reproduce steps (it works fine in every other case). When trying to quit OOo4Kids, the program receive SIGSEGV, Segmentation fault. Here is the compromised fragment of code:

         ImplListBox::~ImplListBox()
 	  {
 	  	delete mpHScrollBar;
 	  	delete mpVScrollBar;
 	  	delete mpScrollBarBox;
 	  }

The problem lies in the line

 delete mpVScrollBar


No idea how to fix that yet, though...

Twarz 16:21, 19 August 2009 (UTC)

How to solve the problem

At first, we thought that only empty presentations were concerned, therefore we only traced in that case. After some tests, it appears the problem also exists on presentation with an already existing template... but at another place in the source code. We fear that this might repeat and that each case will lead to a different location in the code. It would take much time to correct everything manually, therefore a way to fix everything at once would be to disable the "Create" button during the preview, and to reactivate it when the preview is entirely over. Therefore, any timer problem would be avoided.

Twarz 10:02, 31 August 2009 (UTC)

Problem reported on IssueZilla.

Performance: Impress' drag'n'drop

How to reproduce

  • Open a new impress document, select the "from template" option and click next
  • click next, next, next, then create
  • click on "notes"
  • Drag the preview of any slide

=> huge slowdown, more or less slow depending on the background of the slide.

I will try and correct this performance issue as a part of my training perdio subject.

Twarz 14:26, 1 September 2009 (UTC)

Where is the problem

What is exactly happening

How to solve the problem

Crash: argument in command line

How to reproduce

  • Launch OOo4Kids with any argument on the command line (Linux)
  • ... that's it.

Where is the problem

desktop/source/app/cmdlineargs.cxx:581

What is exactly happening

if (i == 7 && m_pGroupDefinitions[nGroupId].nCount == 8) => nParam ~= 30000000 So obviously, "m_aBoolParams[nParam]" will crash.

How to solve the problem

Wrong solution: if (!(i == 7 && m_pGroupDefinitions[nGroupId].nCount == 8)). Not clean, but fix the issue without altering the rest of the program.

True solution: find why BoolParam nParam = m_pGroupDefinitions[nGroupId].pGroupMembers[i]; returns suck an illogical result, and fix it.

Crash: insert a picture in a header of a writer file

Library: libswlx.so

Work on XOs

Quick Introduction

After receiving the XOs, Kidd and myself will be able to engage into the most interesting part of our training period: adapting OOo4Kids on Sugar, and being able to run it on the XO laptops. We will basically proceed as follow: experiment, locate, correct, meaning we will spend a lot of time on merely using OOo4Kids, trying to find bugs and / or feature to optimize, then use the tools at our disposition (gdb, valgrind, callgrind...) to locate them precisely in the code, then with Eric Bachard's and Pierre Pasteau's help do our best to correct and suggest a working patch that will be submitted to the next version of OOo4Kids and maybe even OOo. Our objectives are as follow:

  • submit at least 2 visible performance improvement (one per student, possibly more if time allows it);
  • submit at least 2 UI improvement (just as above, at least one per student);

Any progress made on the XOs or on OOo4Kids itself will be reported on this page, in the corresponding section. Progress worth mentioning on the XO will also be reported on this blog.

Promoting the XO

Receiving the XO will also allow us to assist Eric Bachard during a conference that will take place in october. Many points will be presented during this conference: the Education project, in order to make OOo4Kids more known of the public, our own project of contributing to the source code, and of course a presentation of the XO, their capacities, their goal, and an overall view of the OLPC fundation.

Quick Presentation of the XO

XO's laptops are an initiative of the OLPC (One Laptop Per Children) association. They are low-cost laptops (available for poor children) with low performances using Sugar (a Linux using neither KDE nor Gnome but a new type of interface). There are three type of XO, the XO-1, the XO-1.5 and the XO-2.

The XO-1 is using an AMD Geode LX-700@0.8W processor with a CPU frequency of 433MHz, and an AMD CS5536 South Bridge chipset. It has 256Mo of RAM and 1GO of flash memory. The XO-1.5 is a XO-1 update as the processor is now a VIA C7-M with a CPU frequency of 1GHz and 4GO of flash memory (and some other things).

The XO-1 laptop with the Sugar desktop




The XO-2 really changes the laptop's shape, as there is no more keyboard but a double touch-sreen that will allow the development of whole new activities.

The XO-2, yet to come








Direct Work on XOs

Sugarizing OOo4Kids

We have to Sugarize OOo4Kids, which means that in the end OOo4Kids must run on the XO as a sugar_compatible activity. Those sugar-activities provide many features interesting and useful for children, so having OOo4Kids run under those conditions would be pretty nice.

-Already done: setting sugar-specific X properties on OOo4Kids' window -Current work: setting up a new organization for the files.

Notes:
     -keep the current organization and use symlinks
     -use the organization that already appears in instsetoo_native/unxlngi6.pro/.../install/fr/*

Many thanks to Stephan Bergmann for his indications !

About the X Properties

As explained, we need to set new properties on the main window for the program to be fully compatible with some features of Sugar. Those informations are given on the command line by sugar when the program is launched. But in OOo4Kids' case, it wouldn't be easy to conveniently receive those informations from the beginning and bring them at the proper place... So we used a work-around, greatly inspired by the sug script and the libsugarize.so (all credits for those two amazing tools go to Catmoran ). This create enable a program to run under Sugar, but without being entirely compatible with all the Sugar features. We used the idea of going through a script that will export all of these datas into the environment before launching the program. Then, in the source code, we call the XChangeProperty function of the XLib to set those new datas and we're done. The implementation has been done in the new source file SugarProperties.cxx, and everything that changed is located in vcl/unx/source. Everything is protected using a new variable: XO_INTEL. It works just like the OOo4Kids one: it will prevent the compilation of certain fragments of the code unless the user has specified it.

Twarz 13:32, 9 November 2009 (UTC)

Improving OOo4Kids' Performances

Memory

XOs are laptops with a really low amount of RAM. Therefore, one of the major objectives will be to make sure that the memory leaks are close to none. If not, OOo4Kids might be unusable on the laptops. We will probably be using mainly Valgrind in order to locate and correct the biggest leaks. Many tests will be carried out:

  • letting the program run for a long time, with a huge amount of information provided;
  • filling an Impress wizard with a lot of information, then cancel (this test has been proved positive on the current version of OOo4Kids and will require special attention);
  • deleting figures, text, drawings... during a session, and make sure the memory that was used is correctly freed;
  • Check previews and slideshows (Impress' wizard);
  • checking the limit of the documents and try to expand it by suppressing unused memory;
  • simply checking a normal, basic usage of the different applications
  • secondary: location and termination of eventuals invalid frees/delete

The idea is to see how much memory OOo4Kids is using at the very beginning, when displaying the Start Center, when the user hasn't done anything. Then, carry on the tests, cancel everything, and come back to the Start Center. If the amount of memory used by OOo4Kids is different at that time, then there is a memory leak.

Here is how we will proceed to locate the memory leaks once they have been recognized as such (this is also a more precise way to see if there is indeed a memory leak). We will be using Valgrind (the following values are based on milestone 56, and will be updated as soon as the next milestone will be available).

First, launch OOo4Kids with Valgrind, reach the Start Center, and quit immediatly. Here is the result:

 ==578== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 1418 from 3)
 ==578== malloc/free: in use at exit: 2,240,486 bytes in 10,319 blocks.
 ==578== malloc/free: 41,644 allocs, 31,326 frees, 10,481,760 bytes allocated.
 ==578== For counts of detected errors, rerun with: -v
 ==578== Use --track-origins=yes to see where uninitialised values come from
 ==578== searching for pointers to 10,319 not-freed blocks.
 ==578== checked 22,363,496 bytes.
 ==578== 
 ==578== LEAK SUMMARY:
 ==578==    definitely lost: 13,796 bytes in 327 blocks.
 ==578==      possibly lost: 122,753 bytes in 89 blocks.
 ==578==    still reachable: 2,103,937 bytes in 9,903 blocks.
 ==578==         suppressed: 0 bytes in 0 blocks.

As we can see, there are already some unfreed allocations, but we will overlook them for now. We can now start carrying on the tests, using these values as base value. The idea is that there should always be the same difference of allocs-free - this would mean the action we just done was entirely and correctly freed, meaning the remaining "leaks" are only part of the base value. If the difference is greater, it means the test is positive, and all the memory we just used hasn't been correctly freed. It can be dangerous: if we use OOo4Kids for too long, the used memory will become greater and greater, and cause a crash. Let's try to merely open a Writer document, come back to the Start Center, and quit OOo4Kids. Here is the Valgrind log:

 ==32656== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2299 from 4)
 ==32656== malloc/free: in use at exit: 2,374,725 bytes in 10,830 blocks.
 ==32656== malloc/free: 64,424 allocs, 53,595 frees, 23,395,607 bytes allocated.
 ==32656== For counts of detected errors, rerun with: -v
 ==32656== Use --track-origins=yes to see where uninitialised values come from
 ==32656== searching for pointers to 10,830 not-freed blocks.
 ==32656== checked 29,136,480 bytes.
 ==32656== 
 ==32656== LEAK SUMMARY:  
 ==32656==    definitely lost: 13,796 bytes in 327 blocks.
 ==32656==      possibly lost: 136,449 bytes in 97 blocks.
 ==32656==    still reachable: 2,224,480 bytes in 10,406 blocks.
 ==32656==         suppressed: 0 bytes in 0 blocks.

Base value: 41644-31326 = 10318

New value: 64424-53595 = 10829

There IS a memory leak. The check the gravity of the leak, we just have to take a look at the "Leak Summary".

Base Value: 13 796 + 122 753 + 2 103 937 = 2 240 448 bytes.

New Value: 13 796 + 136 449 + 2 224 480 = 2 374 725 bytes.

Meaning, there is a leak of 134 277 bytes. It's not too much, this leak is not an urgent matter, but it still represent a minor risk.

This is basically how to proceed with finding a memory leak in the program. To locate it it the code, we will have to use some options of Valgrind and add the debugging symbols to the libraries concerned in the leak.

CPU

Just as for the memory, the XOs laptops have limited ressources in term of CPU. This will be our second important objective: globally optimize OOo4Kids and get rid of any situation that could lead to a 100% use of the CPU.As for the memory leaks, many tests will be made:

  • opening a high number of documents at once, filled with informations;
  • letting the program run alone during different phases of it's execution;
  • fill the dialogue boxes in the wizards (positive on the current version in the Impress wizard) and try to fix the huge slowdown that might result of it;
  • give a special attention to the Impress application which seems to be prone to crashing and is globally under-optimized;

Controlling the CPU usage will be done with two tools on the XO: the shell command "top", that shows a high amount of information about every process being run (including, of course, the % of CPU the process uses), and gdb. How ? Pretty simple. First, run OOo4Kids normally, and find some conditions that will lead to a 100% CPU usage. Then, using gdb, repeat the same condition and stop the program at the right time. This will give us a first indication of where the problem is inside the code. At this point, we will have to read the code and understand what is going on, understand what the code does, and try to find a way to make it do it faster.

Improving OOo4Kids' UI

As precised in the introduction, one of the goal of this training period is to make us develop improvements and new elements in the UI, or improving existing elements.








One page of the Impress Wizard

One of the most likely addition that will be made is a new wizard for the Writer application which for now have none. Based on the Impress wizard, it will suggest at most three pages for the user to personify the document he is about to create. It will therefore be slightly simplified compared to the Impress wizard. It will be created using the same portion of code, for the greatest part located in the file sd/source/ui/dlg/dlgass.cxx

IRC Meetings

IRC meetings logs take a lot of place, therefore they have been moved to this page which will be updated for every future meeting we will have.

Documentation

First bits of documentation are available here. Few examples until we start for good and documentation will be migrated here.

Planning

Current Work

Here are the results of the day, yet to be classified. Just here to stock informations until we find the time to properly classify them.

Patch suppressing the "Java" and "Security" tab from the Options list has been provided and is currently being polished. It does work, but still needs to be cleaned a bit. Basically, this patch suppresses the instances of the buttons inside the tabs themselves (in order not to occupy memory uselessly), and get rid of anything related to these two tabs in the source code and in the ressources.

Twarz 16:44, 16 September 2009 (UTC)

OOo4Kids' test by children

How the test is planned

First of all, I ask a bunch of question about how the child uses office softwares, here are the question:

Do you know what an office software is?

Have you ever used an office software?

Where are you using it the most? Why?

Which application of an office software are you using the most?

Then, I ask him to go out and I launch OOo, I ask him to tell me what is each application of the start center and tell him to use it as he wishes, and then I go on the application he is the most accostumed to and I ask him to tell me what is doing each icons on the toolbar, without telling him if he is wrong or not. Then I ask him to go out and I start OOo4Kids and I follow the exact same protocol. Then I launch both and ask him which one is his favorite and why.

Results

For now, there is just one result, the next test is coming next week. The child is 9 years old.

Do you know what an office software is? No (She doesn't know the word, so i explained it).

Have you ever used an office software? Yes.

Where are you using it the most? Why? In school, during informatics class to learn how to write some documents.

Which application of an office software are you using the most? "The one to write documents" (Writer), never used a calc or impress type application.

Here we go for the OOo part of the main test with Writer: He writes text, change its shape at will with no problem, not really that hard to use. Then i ask him about icons, and there is not real problems about what they do in the first time, but he doesn't know what a PDF file is. Then, we get to the copy/paste part and doesn't know what it is with the first sight and then understand by seeing the words. After that, he is quite lost with everything about "hypertext", "table" and even "find & replace", he doesn't even know how to use it. He doesn't understand the "new" icon, and he is not at ease with what is inside: - Doesn't know what are HTML, XML, master document, formula.

Then, the OOo4Kids part: He understands what are the applications of the start center, except for calc. For the beginning, that's the same use of writer than OOo, so there is no problem. There is still the problem about "what is a PDF?". In a first time, he thinks that the "view" icon is a zoom function. Still the same problem about the "new" icon.

About "using" writer, he said that there is no real difference, but he is more attracted by OOo4Kids because it is "more beautiful". He likes the fact that draw options are available at the start of writer. I asked him which one he preferred and told me OOo4Kids because of what is said before, but he even prefers the one used at school because he is more accostumed to it.

Personal tools