Refresh issue with FixedText controls (Linux and Windows only)

Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Refresh issue with FixedText controls (Linux and Windows only)

eric b-3
Hi,

I have refresh ( flickering ?) issue with FixedText controls in  
Toolbox, but only on Windows and Linux.  On Mac OS X, things are  
perfect, no problem.

Specifications are :

Let's consider a rectangle (for instance, a button), in a toolbox  
object.
* when the mouse cursor rolls over on button, the  
VCLEVENT_TOOLBOX_HIGHLIGHT is sent when entering in the button  
rectangle.
* when the mouse cursor goes out of the area, the  
VCLEVENT_TOOLBOX_HIGHLIGHTOFF  is sent.

Receive VCLEVENT_TOOLBOX_HIGHLIGHT triggers a   aFixedText.Show()
Receive VCLEVENT_TOOLBOX_HIGHLIGHTOFF triggers all FixedText controls  
to be hidden ( e.g.  aFixedText.Hide() )

So when the mouse cursor is moved from left to right, we see the  
following events occur :

VCLEVENT_TOOLBOX_HIGHLIGHT is catched, next is  
VCLEVENT_TOOLBOX_HIGHLIGHTOFF ... VCLEVENT_TOOLBOX_HIGHLIGHT ... and  
so on, alternatively.

The result is :
no text shown ... show fixed text1  .. hide all fixed text ... show  
fixed text2 ... hide alll

The relevant code is :

IMPL_LINK( BackingWindow, DecoToolboxHdl, VclWindowEvent*, pEvent )
{
     if( pEvent && pEvent->GetId() == VCLEVENT_TOOLBOX_HIGHLIGHT )
     {
#ifdef DEBUG
         fprintf(stdout, "Toolbox nItemId = %d \n",  
maToolbox.GetHighlightItemId() );
#endif
         switch ( maToolbox.GetHighlightItemId() )
         {
             case nItemId_Calc:
                 maCalcMessageText.Show();
                 break;
             case nItemId_Draw:
                 maDrawMessageText.Show();
                 break;
             case nItemId_Impress:
                 maImpressMessageText.Show();
                 break;
             case nItemId_Info:
                 maOpenMessageText.Show();
                 break;
             case nItemId_Writer:
                 maWriterMessageText.Show();
                 break;
             case nItemId_Extensions:
             case nItemId_Reg:
             case nItemId_TplRep:
             default:
                 break;
         }
     }
     else if( pEvent && pEvent->GetId() ==  
VCLEVENT_TOOLBOX_HIGHLIGHTOFF )
     {
         maCalcMessageText.Hide();
         maDrawMessageText.Hide();
         maImpressMessageText.Hide();
         maOpenMessageText.Hide();
         maWriterMessageText.Hide();
     }
     return 0;
}



The issue :

When moving the mouse cursor fastly between two buttons, sort of  
flicker appear, probably caused by either performance issue, or  
something missing in the code. In my mind, the term flicker, happens  
to be the FixedText background who appears (just "flickering"), and  
this causes a very bad user experience : most of children, play with  
the show / hide startcenter feature naturaly ...

If this can help, at initialisation, I have used  SetPaintTransparent
(), for every FixedText control, and tested Erase() and several other  
methods since, to make the FixedText control background transparent  
(means  : no longer displayed). Unfortunaly, nothing helped until now.


Is there something missing, or is the current solution plain wrong  
(please tell me why), or is there a better implementation on Mac OS X  
than elsewhere ? (double buffering or something issue on Linux, or  
missing Invalidate somewhere or ... ? ). Other possibility : did I  
implement the algo ( Show() / Hide() ) at too hight level, causing  
performance issues ? But then, why Mac OS X fine in this case ?

The current workaround I had in mind was to use a timer:  enter in a  
rectangle triggers a timer (e.g 200 ms or a same magnitude value) .  
The first time we roll over a button, the Timer starts. If ever other  
VCL events are detected, until the timeout is reached, no way to  
hide / show again (using Timer::bIsActive() information ). This  
means, there will be always a delay before a string appears, starting  
the second time we roll over a button with the mouse cursor.  But I  
consider this solution as a workaround, and I ask here for something  
better.

I'm not a native speaker, and my english is not precise, so feel free  
to ask for further information.


Thanks in advance for any help !
Eric Bachard


--
qɔᴉɹə
Education Project:
http://wiki.services.openoffice.org/wiki/Education_Project
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news





Reply | Threaded
Open this post in threaded view
|

Re: Refresh issue with FixedText controls (Linux and Windows only)

philipp.lohmann
Hi,

IMHO this is going to flicker somewhat whatever you do, since you need
to erase the FixedText and the paint another one.

On the Mac you see this not because all drawing is double buffered; you
do the "flickering" stuff in the back buffer which then gets copied in a
single step when the mac comes around to update the actual window.

If you wanted to emulate this behavior on all platforms you could have
your own control that does this using a VitualDevice to prepare its text
and then only copy that to the window when the ::Paint method gets
called. But that is probably a bit overblown.

You could also simplify things by not having different FixedTexts but
using only one, calling SetText on that one FixedText when you need to
change the text. This will also flicker at least a little since here
also the window needs to get erased and then the new text drawn. But it
will save a lot of clip region operations (removing the FixedText from
the parents clip region and inserting the other one) which will gain
some performance.

If you have flickering already, do not use SetPaintTransparent and set a
normal background (like solid white for instance). Transparent painting
always causes the all parents up to the first opaque (not transparent)
parent to restore the view, so a lot more painting gets done until
finally the text can be drawn; transparent windows will cause more
flicker, not less.

Just my 2 cents, pl

On 1/18/11 9:51 AM, eric b wrote:

> Hi,
>
> I have refresh ( flickering ?) issue with FixedText controls in
> Toolbox, but only on Windows and Linux.  On Mac OS X, things are
> perfect, no problem.
>
> Specifications are :
>
> Let's consider a rectangle (for instance, a button), in a toolbox object.
> * when the mouse cursor rolls over on button, the
> VCLEVENT_TOOLBOX_HIGHLIGHT is sent when entering in the button rectangle.
> * when the mouse cursor goes out of the area, the
> VCLEVENT_TOOLBOX_HIGHLIGHTOFF  is sent.
>
> Receive VCLEVENT_TOOLBOX_HIGHLIGHT triggers a   aFixedText.Show()
> Receive VCLEVENT_TOOLBOX_HIGHLIGHTOFF triggers all FixedText controls
> to be hidden ( e.g.  aFixedText.Hide() )
>
> So when the mouse cursor is moved from left to right, we see the
> following events occur :
>
> VCLEVENT_TOOLBOX_HIGHLIGHT is catched, next is
> VCLEVENT_TOOLBOX_HIGHLIGHTOFF ... VCLEVENT_TOOLBOX_HIGHLIGHT ... and
> so on, alternatively.
>
> The result is :
> no text shown ... show fixed text1  .. hide all fixed text ... show
> fixed text2 ... hide alll
>
> The relevant code is :
>
> IMPL_LINK( BackingWindow, DecoToolboxHdl, VclWindowEvent*, pEvent )
> {
>     if( pEvent && pEvent->GetId() == VCLEVENT_TOOLBOX_HIGHLIGHT )
>     {
> #ifdef DEBUG
>         fprintf(stdout, "Toolbox nItemId = %d \n",
> maToolbox.GetHighlightItemId() );
> #endif
>         switch ( maToolbox.GetHighlightItemId() )
>         {
>             case nItemId_Calc:
>                 maCalcMessageText.Show();
>                 break;
>             case nItemId_Draw:
>                 maDrawMessageText.Show();
>                 break;
>             case nItemId_Impress:
>                 maImpressMessageText.Show();
>                 break;
>             case nItemId_Info:
>                 maOpenMessageText.Show();
>                 break;
>             case nItemId_Writer:
>                 maWriterMessageText.Show();
>                 break;
>             case nItemId_Extensions:
>             case nItemId_Reg:
>             case nItemId_TplRep:
>             default:
>                 break;
>         }
>     }
>     else if( pEvent && pEvent->GetId() == VCLEVENT_TOOLBOX_HIGHLIGHTOFF )
>     {
>         maCalcMessageText.Hide();
>         maDrawMessageText.Hide();
>         maImpressMessageText.Hide();
>         maOpenMessageText.Hide();
>         maWriterMessageText.Hide();
>     }
>     return 0;
> }
>
>
>
> The issue :
>
> When moving the mouse cursor fastly between two buttons, sort of
> flicker appear, probably caused by either performance issue, or
> something missing in the code. In my mind, the term flicker, happens
> to be the FixedText background who appears (just "flickering"), and
> this causes a very bad user experience : most of children, play with
> the show / hide startcenter feature naturaly ...
>
> If this can help, at initialisation, I have used  
> SetPaintTransparent(), for every FixedText control, and tested Erase()
> and several other methods since, to make the FixedText control
> background transparent (means  : no longer displayed). Unfortunaly,
> nothing helped until now.
>
>
> Is there something missing, or is the current solution plain wrong
> (please tell me why), or is there a better implementation on Mac OS X
> than elsewhere ? (double buffering or something issue on Linux, or
> missing Invalidate somewhere or ... ? ). Other possibility : did I
> implement the algo ( Show() / Hide() ) at too hight level, causing
> performance issues ? But then, why Mac OS X fine in this case ?
>
> The current workaround I had in mind was to use a timer:  enter in a
> rectangle triggers a timer (e.g 200 ms or a same magnitude value) .
> The first time we roll over a button, the Timer starts. If ever other
> VCL events are detected, until the timeout is reached, no way to hide
> / show again (using Timer::bIsActive() information ). This means,
> there will be always a delay before a string appears, starting the
> second time we roll over a button with the mouse cursor.  But I
> consider this solution as a workaround, and I ask here for something
> better.
>
> I'm not a native speaker, and my english is not precise, so feel free
> to ask for further information.
>
>
> Thanks in advance for any help !
> Eric Bachard
>
>

--

<http://www.oracle.com/>
Philipp Lohmann | Software engineer

OracleOpen Office Development

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

<http://www.oracle.com/commitment>

       

Oracle is committed to developing practices and products that help
protect the environment




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Refresh issue with FixedText controls (Linux and Windows only)

eric b-3
Le 24 janv. 11 à 18:24, Philipp Lohmann a écrit :

> Hi,
>


Hi Philipp,


> IMHO this is going to flicker somewhat whatever you do, since you  
> need to erase the FixedText and the paint another one.


Ok.


> On the Mac you see this not because all drawing is double buffered;


Is it possible to use double buffering on Windows and Linux too .. or  
not ?



> you do the "flickering" stuff in the back buffer which then gets  
> copied in a single step when the mac comes around to update the  
> actual window.
>

That's what I thought after some tries : Mac OS X is the only one  
using true double-buffering. I must admit in my mind (and I was  
wrong) Windows should, but looks like it does not :-/


> If you wanted to emulate this behavior on all platforms you could  
> have your own control that does this using a VitualDevice to  
> prepare its text and then only copy that to the window when  
> the ::Paint method gets called. But that is probably a bit overblown.


If I understand you correctly, you want to say that, on Windows and  
Linux, only double-buffering emulation is possible ?

The "emulation" solution look interesting, but looks a bit  
complicated, and on slow machines (like XO) I'm not sure it will work  
well. Last but not least, maybe there is some hidden drawback.


>
> You could also simplify things by not having different FixedTexts  
> but using only one, calling SetText on that one FixedText when you  
> need to change the text.


Ok,  I'll try what you suggest. I was wondering which one was the  
most costly at runtime : only one or set all and Show() / Hide() only  
one.


> This will also flicker at least a little since here also the window  
> needs to get erased and then the new text drawn.


Indeed


> But it will save a lot of clip region operations (removing the  
> FixedText from the parents clip region and inserting the other one)  
> which will gain some performance.
>

Ah, I missed this point.



> If you have flickering already, do not use SetPaintTransparent and  
> set a normal background (like solid white for instance).
> Transparent painting always causes the all parents up to the first  
> opaque (not transparent) parent to restore the view, so a lot more  
> painting gets done until finally the text can be drawn; transparent  
> windows will cause more flicker, not less.
>


Your explanation is extremely interesting : I had no clue where  
cycles were lost, and the way transparency works explains a lot.


> Just my 2 cents, pl
>



I got some time today, and if nothing goes wrong, I should report  
feedback soon. To tell you more, I'm playing with annotation mode,  
and the idea is to provide an interactive mode, without any toolbar  
nor menu, and at the end, modify Draw behavior


As usual, thanks a lot for your golden advices !!
Eric

--
qɔᴉɹə
Education Project:
http://wiki.services.openoffice.org/wiki/Education_Project
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news





Reply | Threaded
Open this post in threaded view
|

Re: Refresh issue with FixedText controls (Linux and Windows only)

eric b-3
In reply to this post by philipp.lohmann
Philipp Lohmann a écrit :
> Hi,

Hi Philipp,


> On the Mac you see this not because all drawing is double buffered; you
> do the "flickering" stuff in the back buffer which then gets copied in a
> single step when the mac comes around to update the actual window.
>
> If you wanted to emulate this behavior on all platforms you could have
> your own control that does this using a VitualDevice to prepare its text
> and then only copy that to the window when the ::Paint method gets
> called. But that is probably a bit overblown.


After lot of tries, and some algo improvments, I fear this will be the
only relible solution : flickering is always present on both Windows and
Linux.

Could you please give me some tracks, or point me existing example in
the code, to implement this VirtualDevice ? (of course the code will be
reversed if you consider it interesting for OpenOffice.org)


> You could also simplify things by not having different FixedTexts but
> using only one, calling SetText on that one FixedText when you need to
> change the text. This will also flicker at least a little since here
> also the window needs to get erased and then the new text drawn. But it
> will save a lot of clip region operations (removing the FixedText from
> the parents clip region and inserting the other one) which will gain
> some performance.
>
> If you have flickering already, do not use SetPaintTransparent and set a
> normal background (like solid white for instance). Transparent painting
> always causes the all parents up to the first opaque (not transparent)
> parent to restore the view, so a lot more painting gets done until
> finally the text can be drawn; transparent windows will cause more
> flicker, not less.

Indeed: applying your suggestion, helped, but flickering is still present :/


Kind regards,
Eric
--
Education Project:
http://wiki.services.openoffice.org/wiki/Education_Project
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Refresh issue with FixedText controls (Linux and Windows only)

philipp.lohmann
Hi,

On 2/16/11 9:23 AM, eric wrote:

> Philipp Lohmann a écrit : If you wanted to emulate this behavior on
> all platforms you could have your own control that does this using a
> VitualDevice to prepare its text and then only copy that to the window
> when the ::Paint method gets called. But that is probably a bit
> overblown.
>
>
> After lot of tries, and some algo improvments, I fear this will be the
> only relible solution : flickering is always present on both Windows
> and Linux.
>
> Could you please give me some tracks, or point me existing example in
> the code, to implement this VirtualDevice ? (of course the code will
> be reversed if you consider it interesting for OpenOffice.org)
You would have a VirtualDevice that spans the area where you currently
have "flickering" problems. So when the need to change the contents of
that area arises, you can do all painting in that backbuffer and only
copy it to window when you're done.

So like this:

#include "vcl/virdev.hxx"

void UpdateAffectedArea()
{
     VirtualDevice aDev;
     aDev.SetBackground( Color( < my background color > ) );
     aDev.SetOutputSizePixel( < my size in pixel > );

     maFixedText.Draw( &aDev, <position>, <size>, <flags> );

     maWindow.DrawOutDev(
<position in window>, <my size in pixel>,
         Point( 0, 0 ), <my size in pixel>,
&aDev );

}

However there is a caveat: since you do not have a real FixedText
control there anymore, accessibility will not work for this area, so no
screen readers etc. Not worth dropping that for a little flicker IMHO,
but possible.

Kind regards, pl

--

<http://www.oracle.com/>
Philipp Lohmann | Software engineer

OracleOpen Office Development

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

<http://www.oracle.com/commitment>

       

Oracle is committed to developing practices and products that help
protect the environment




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Refresh issue with FixedText controls (Linux and Windows only)

eric b-3

Le 17 févr. 11 à 13:01, Philipp Lohmann a écrit :

> Hi,
>


Hi Philipp,


> On 2/16/11 9:23 AM, eric wrote:
>> Philipp Lohmann a écrit : If you wanted to emulate this behavior  
>> on all platforms you could have your own control that does this  
>> using a VitualDevice to prepare its text and then only copy that  
>> to the window when the ::Paint method gets called. But that is  
>> probably a bit overblown.
>>
>>
>> After lot of tries, and some algo improvments, I fear this will be  
>> the only relible solution : flickering is always present on both  
>> Windows and Linux.
>>
>> Could you please give me some tracks, or point me existing example  
>> in the code, to implement this VirtualDevice ? (of course the code  
>> will be reversed if you consider it interesting for OpenOffice.org)
> You would have a VirtualDevice that spans the area where you  
> currently have "flickering" problems.


If this can help, most of the flicker occurs whith  Hide() method.  
Don't ask me why :)


> So when the need to change the contents of that area arises, you  
> can do all painting in that backbuffer and only copy it to window  
> when you're done.
>
> So like this:
>
> #include "vcl/virdev.hxx"
>
> void UpdateAffectedArea()
> {
>     VirtualDevice aDev;
>     aDev.SetBackground( Color( < my background color > ) );
>     aDev.SetOutputSizePixel( < my size in pixel > );
>
>     maFixedText.Draw( &aDev, <position>, <size>, <flags> );
>
>     maWindow.DrawOutDev(
> <position in window>, <my size in pixel>,
>         Point( 0, 0 ), <my size in pixel>,
> &aDev );
>
> }
>


Thank you very much for this explanation, I'll start today with that,  
and I hope I'll make progress in the coming week.



> However there is a caveat: since you do not have a real FixedText  
> control there anymore, accessibility will not work for this area,  
> so no screen readers etc. Not worth dropping that for a little  
> flicker IMHO, but possible.
>


I'm not sure to understand : when the mouse cursor rolls over one  
button, it it not over the text area, but on the button area, no ? So  
maybe accessibility will continue to work ? (but maybe I missed  
something).

Anyway, I consider the flicker as a blocker (avoiding us to release  
1.2) and I'd like to see how things work once fixed.


Thanks again for your golden advices :)

Eric

--
qɔᴉɹə
Education Project:
http://wiki.services.openoffice.org/wiki/Education_Project
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news





Reply | Threaded
Open this post in threaded view
|

Re: Refresh issue with FixedText controls (Linux and Windows only)

eric b-3
In reply to this post by philipp.lohmann
Philipp Lohmann a écrit :
> Hi,

Hi Philipp,

>
> You would have a VirtualDevice that spans the area where you currently have "flickering" problems. So when the need to change the contents of
> that area arises, you can do all painting in that backbuffer and only copy it to window when you're done.
>
> So like this:


1)

> #include "vcl/virdev.hxx"

OK, using virdev.hxx

2)
> void UpdateAffectedArea()
> {


Ok. More precisely, I added UpdateAffectedArea as private method in
BackingWindow class, and works perfectly.

3)

>     VirtualDevice aDev;

Done

4)
>     aDev.SetBackground( Color( < my background color > ) );

Done, using COL_TRANSPARENT (found somewhere in tools)

5)

>     aDev.SetOutputSizePixel( < my size in pixel > );

Ok, done.

6)

>     maFixedText.Draw( &aDev, <position>, <size>, <flags> );


What does the Draw method ?

I was not sure, so I added a parameter in the signature ( like
Point(0,0) per see the compiler cry and propose me correct candidates,
and I found the header location <vcl/fixed.hxx> (yes, I'm lazy sometimes :)

So I had a look at the implementation and the Draw method does nothing
(see vcl/source/control/fixed.cxx:634).

So I removed the action below and it works the same. At least, is seems to.

7)


>     maWindow.DrawOutDev(
> <position in window>, <my size in pixel>,
>         Point( 0, 0 ), <my size in pixel>,
> &aDev );

Works : I can draw/hide text without use Show(), Hide()


... but unfortunaly I still got the flicker. Less, but still flicker
(tested on Linux).

What did i wrong ? (below, some important lines, just in case I did
something completely wrong). Thanks in advance for any hint.


Kind regards,
Eric




void BackingWindow::UpdateAffectedArea()
{
     long nYPos = maControlRect.Top() + MESSAGE_OFFSET_Y /* value:295 */;
     Size aWindowSize( GetSizePixel() );
     Size aControlSize = maControlRect.GetSize();
     maControlRect = Rectangle( Point(   (aWindowSize.Width() -
aControlSize.Width()) / 2 ,
                                         (aWindowSize.Height() -
aControlSize.Height()) / 2 ),
                                 aControlSize );
     maMessageText.SetPosSizePixel( Point( (aWindowSize.Width()
maMessageSize.Width() + STRING_OFFSET_X) / 2 , nYPos ),
                                   Size( maControlRect.GetWidth(),
maMessageSize.Height() ) );

     VirtualDevice aDev;
     aDev.SetBackground( Color( COL_TRANSPARENT ) );
     aDev.SetOutputSizePixel( maMessageSize );


     /*
      * DrawOutDev signature, taken from <vcl/outdev.hxx>
      * void DrawOutDev(  const Point& rDestPt, const Size& rDestSize,
      *                   const Point& rSrcPt,  const Size& rSrcSize,
      *                   const OutputDevice& rOutDev );
      */

     DrawOutDev(Point( (aWindowSize.Width() - aControlSize.Width()) / 2
, (aWindowSize.Height() - aControlSize.Height()) / 2 ),
         Size( maControlRect.GetWidth(), maMessageSize.Height() ),
         Point( 2000,2000) /* draw offscreen ?, else garbage at
Point(0,0) */,
         Size(0,0),
          aDev );
}

IMPL_LINK( BackingWindow, DecoToolboxHdl, VclWindowEvent*, pEvent )
{
     if( pEvent && pEvent->GetId() == VCLEVENT_TOOLBOX_HIGHLIGHT )
     {

        ...
        ...

        (all cases)

     }
     else if( pEvent && pEvent->GetId() == VCLEVENT_TOOLBOX_HIGHLIGHTOFF )
     {
         maMessageText.SetText( maEmptyString );
         maMessageSize = Size( maMessageText.GetTextWidth(
maWriterString ), maMessageText.GetTextHeight() );
     }

     UpdateAffectedArea(); /* made once only*/

     return 0;
}

--
Education Project:
http://wiki.services.openoffice.org/wiki/Education_Project
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]