[gcompris-devel] gcompris and gnome 2.2

[Olivier Samyn]

Hi all, 

To explain a bit the patch I submitted and to resume the situation here
are some tips about the problem:
 - Since Gnome 2.2 shipped out last week, no distribution ships it
already (except debian devel packages...)
 - The problem I pointed out come with >= 2.2.0 versions of
libgnomecanvas.

Also, after Marius suggest, I posted a bug report to gnome's bugzilla to
understand if the problem is a mistake into the new gnomecanvas's code
or if it is a new behaviour that gcompris will have to work with. We'll
see with time...

So, if some body (like me) want's to use gcompris with a gnome 2.2
version, we have the solution and a redy to apply patch.

Now that I fixed this issue for me, I'll be ready to take a look to the
python bindings...

Olivier


Le mar 11/02/2003 à 09:33, Christof Petig a écrit :
> 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
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> gcompris-devel mailing list
> gcompris-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gcompris-devel
-- 
Olivier Samyn <osamyn at ulb.ac.be>