[gcompris-devel] Question in submarine

[Bruno Coudoin]

Le lun 18/08/2003 à 20:22, pgeorges a écrit :
> Hilaire Fernandes wrote:
> > On 18 Aug 2003 00:11:15 +0200
> > Bruno Coudoin <bruno.coudoin at free.fr> wrote:
> > 
> >       
> >       Thanks for the clarification. I will change the tank to display a water
> >       level intead of a number. It will be I hope more visual for the kids.
> >       
> >       For the gnome API, I am sorry for it. I agree with you that it lacks
> >       documentation and we suffer bugs.  You entered into another complexity
> >       using the afine to rotate the submarine and I feel your pain.
> >   
> > 
> > What about defining even a higher level API specific to GCompris however
> > the GnomeCanvas. You can have a lot of easier function to be use than
> > the GnomeCanvas plus you will add an abstract layer between GCompris and
> > the GnomeAPI, which will be less sensitive to API change in Gnome.
> 
> Never forget the kiss principle (keep it simple stupid) !
> GCompris development and overall bug hunting would have been *far* 
> easier if a decent language and toolkit were used. My choices are :
> 1. Java
> 2. Qt (and not KDE)
>
> That way, you get rid of most of the dependancies we encountered with 
> packages that always change in distributions. Gnome bugs are the worst, 
> and I found some API that were documented, not implemented, and then 
> removed in a later version, because too difficult to make it work 
> properly on this whole mess.
> 
I don't want to overly defend gnome but deprecation happens on any
library. Don't we have deprecated management in Java ?
So wathever you choose, the library will always moves under you and
hopefully it also means its alive ;)

> Bruno made a very nice plugin API for GCompris, but agree that you'll 
> never win a race with a Ford T.
> 
> Concerning Java, please, don't argue about performance. Nothing is worse 
> than Gnome. Just look at the poor animations in Gcompris : I encountered 
>   a lot of speed refreshing issues, that were better handled in Java 
> (and automatically !).
> 
> I am also perfectly sure that there are a lot of memory leaks in 
> Gcompris that are impossible to remove (it's too late, just have a look 
> to all the glib stuff). It would need a long code review.
> 
For the memory leak, that's the case. I checked it recently and there
are some for sure. I tryied tu run memprof with no sucess on it. Any
help appreciated.

> If a switch to Java is decided, I will actively participate, even if 
> this will allow this program to run under Windows !
> 
I will never go this path. I also used extensively java at work and like
it (expept the swing layout manager). gcompris could probably be
implemented using the java2D api.

Unfortunatly java is not free and we cannot accept to distribute non
free software to schools. Nor we can accept to request home users to DL
and install a such big package for gcompris.
Until Sun decide to free it, it won't make a dent in the free software
comunity.

Bruno.