[gcompris-devel] Segmentation fault CVS

[Bruno Coudoin]

Le jeu 29/01/2004 à 20:36, Olivier Samyn a écrit :
> >>But I do not know if a script that adds a new board directly to the 
> >>gcompris tree is the best solution.
> >>Maybe creating a template application that compil and install from 
> >>itself will be also a good idea.
> >>This way, we can think about independant gcompris plugins like xmms plugins.
> >>They can be maintained by someone other than only you  :)
> >>
> >>    
> >>
> >I agree also. That's two different use cases but both approach could
> >help. 
> >I already discussed with Stasz (from childsplay) about the opportunity
> >to rewrite in python the gcompris core so that we could provide a 100%
> >python gcompris with the boards in python. These board could be provided
> >for windows as well without effort. But let's not dream, this is a lot
> >of work.
> >  
> >
> Seems a good idea from a interoperability point of view...
> 
> But I like the actual idea of having a framework written in C and some 
> facilities to implement the different modules in python or why not other 
> languages (If some one is interested I may try to recycle what is done 
> for python in an other language).
> 
We'd better wait there is a need for that. It needs work to stup and
maintain. I prefer to keep things simple and focus on our needs. If a
perl or tcl community comme to us and plan to implement dozens of
activity in their language of choice, why not.

> But this framework needs probably a better gui abstraction layer than 
> gnome-canvas.
> 
> I think maybe a first step will be something like define a 
> gcompris-canvas API.
> The first implementation will use direct gnome-canvas calls, but with 
> time we may port this gcompris-canvas to other targets like for example 
> pygame.
> 
There is no need to do this. If we go this path, we can just create a
canvaslib on top of pygame and compile gcompris for one or the other.
I mean if the goal is to not rewrite the boards, then there is no need
to rewrap the canvas call. 
One option could be to port the gnomecanvas to SDL. I don't have the
expertise to do a such thing but this may triger some third party
interrest.

> This will need a lot of work on definition of this canvas and on 
> existing modules rewrite but... we will get some evolution...:)
> 
Take care, it's a lot of work. We have 50 different activities !!.

> There are also maybe some other projects interested in such a way of 
> doing... and we may interact...
> 
I am thinking of 2 options for that. pygame and cairo.
For those who don't know it, cairo is still in it's infancy but it maybe
the future. It's vector based, it's SVG, it's a standard. We may even
have this work direct in a browser through SVG plugin.
http://www.cairographics.org/

> But let's talk about all of this maybe as freedem...
> Building futur is easier when all actors are round a table with a good 
> Belgian beer ;)
> 
Sure.

> >>The only issue I foresee comes with i18n: the plugin should handle this 
> >>itself.
> >>If you want, I will try this way of doing.
> >>
> >>    
> >>
> >I don't see your point here. What's the issue and what do you mean by
> >"that compil and install from itself". What to you put in this.
> >  
> >
> I was thinking to real independant modules, that when you want to build 
> them you do not need to rebuild/reinstall gcompris entirely.
> 
> Just like real plugins, you get them from a site, compile and install, 
> no need to have the base program sources...
> 
> And the issue comes from the fact that thos plugins need to have their 
> own gettext po files. They may use the gcompris one for some common 
> translations, but need to have their own for the rest.
> 
I got your point then. A such plugin could request his gettext package.
We could provide this feature through our API.
BTW, having external boards packages is a desirable feature, and
gcompris is designed to support this. In the real world, it's best to
have a single package for the ease of installation.

Bruno.