[gcompris-devel] python crash

[Bruno Coudoin]

Le jeu 24/04/2003 à 19:56, Olivier Samyn a écrit :
> > > But there's a problem in the current gcompris loading process: if a
> > > board is not recognized by any plugin it's still displayed in the menu.
> > > So the python icon will still be there but when you click on it it will
> > > do nothing... (and it doesn't crash gcompris any more)
> > > 
> > > Bruno can you confirm me this behaviour and that an update of the
> > > plugin/boards loading process have to be analysed and discussed...
> > > 
> > Yes, no problem to discuss it. I see several approach :
> > - We remove the board icon and the kid do not see them
> 
> A good solution for distribution when python isn't installed (-> some
> plugins are disabled at compilation time)
> 
> > - We keep the icon and we add a red cross on them to inform they are not
> > available. If he click on it a dialog box tell what's wrong to the user
> > : we miss a plugin capable of handling the type xxx of board... Contact
> > Olivier for more information ;)
> 
> Need to load all plugins, all boards, test if a plugin is available and
> then put or not the cross. (removing it is also a solution)
> This will need some work on the loading process...
> 
> > - <Dream>we download the plugin just in time when the user click on the
> > icon</dream>
> > 
> > What do you suggest ?
> 
> For me the latest solution is the best one ! :)
> Because I already mentioned I have to link gcompris with python instead
> of just the plugin... This also invoque modification of the plugin
> loading processs...
> 
> So what about rewriting this code ? I may try to do it but... I'll no
> more implement a new board during this time... :)
> 
If you ask the kids out there, they will vote for the board but its up
to you ;)

> I think about a process that:
> - Load all boards into a hash table (containing: board filename |
> associated plugin, and other datas like icon)
This already exist but its not a hash but GcomprisBoard already include
a field for its associated plugin. It is filled in the
xxx_is_our_board() method when the board detect the plugin is for it.

> - For each available plugin test:
>   - for each boards that doesn't have a plugin associated, test if there
> is an available plugin and associate it in the hash table.
> Also, each board that doesn't have an associated plugin is removed from
> the list.
> 
To do this, you just need to use the code of board_play(gcomprisboard)
and do the same without the start_board.

> This will be done once at gcompris loading time.
> After that, when a board is selected, it'll load the good plugin.
> 
Agree, Here we join.

> This rewrite will change a little bit the plugin api...
> But I think it' necessary for gcompris evolution no ?
> 
I have no problem changing anything in gcompris as long as we keep
improving it ;)
And that's the case...

> Also, during this rewrite, I'll try to use the glib module functions
> instead of the dlopen one... I think it's more portables and always
> available when gnome is there... This will avoid some #ifdef for HP_UX
> for example no ? What about this ?

Great, OK.

Also, there is a patch from Olivier Berger that 

> I suggest a little patch to be able to code plugins in Python in
> ~/.gcompris/Plugins/python/

Are you ok to include it, its a change in python.c. It makes sense to me
to have a specific dir for python plugins.

Bruno.