[gcompris-devel] gcompris and gnome 2.2

[Christof Petig]

bruno wrote:
> Now for the bug you have, I prefer to wait and/or submitting bugs to
> gnome instead of patching gcompris. Also I have not seen the problem on
> mainstream distribution and nobody else reported that.

I have two independant reports on debian/sid/powerpc & i386, too.

> What is you libgnomecanvas version, on my side I have:
> rpm -qa | grep canvas
> libgdk-pixbuf-gnomecanvas1-0.18.0-3mdk
> libgnomecanvas2_0-devel-2.0.2-1mdk
> libgnomecanvas2_0-2.0.2-1mdk

The problem clearly occurs with libgnomecanvas2_0-2.2.*

I'd opt for the following judgement whether this is a bug in gcompris or 
canvas:

- requiring the app to tell the library that now it has finished all 
modifications to the canvas and redrawing can start is a _big_ 
performance win if the app modifies a lot of canvas items at once! And 
it reduces flicker. So I can understand a possible motivation to make 
redraws explicit.
- This could be done via a timeout(0) callback to hide this change from 
the app developer. Interesting to hear why this was not done (I'm no 
canvas developer).

- if this (explicit redraw request) behaviour is going to stay, we 
should patch gcompris to use the new API as soon as possible. Remember: 
gcompris 2.0 and 2.1 broke on debian/sid by the gnome2.2 transition. And 
shipping gnome2.2 is not what I would call a distribution's mistake.

- if the old version of canvas (2.0) does not suffer from the explicit 
redraw statements, this would even more be a reason to fix gcompris.

- if the behaviour is going to change again (I heard a lot about forks 
and bad reputation of the mainstream canvas on different mailing list, 
this clearly hurts us all), try to help the canvas maintainers get this 
sorted out SOON!

    Christof