[gcompris-devel] python crash

Olivier Samyn osamyn at ulb.ac.be
Thu Apr 24 10:56:09 UTC 2003


> > 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... :)

I think about a process that:
- Load all boards into a hash table (containing: board filename |
associated plugin, and other datas like icon)
- 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.

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

This rewrite will change a little bit the plugin api...
But I think it' necessary for gcompris evolution no ?

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 ?


-- 
Olivier Samyn <osamyn at ulb.ac.be>





More information about the Gcompris-devel mailing list