[gcompris-devel] From the python front (and gnome2.2)...

[Bruno Coudoin]

Le jeu 20/02/2003 à 16:32, Olivier Samyn a écrit :
> Hello all,
> 
> What's new about my python bindings... It's in progress but... here are
> some new issues:
> 
> 1) I ported the python and gnome2.2 code to Gcompris 2.3. (Gnome 2.2 is
> attached to this message)
> 

Thanks, it should help those have refresh issues.

> 2) There's a missing copy of gcompris_shapebg.jpg in
> share/gcompris/boards/skin/default ... seems to be a packaging
> problem... but it prevents all shape games to work.
> 
Fixed.

> 3) I found where the linking problem with the python code was. It comes
> from the loading process used in GCompris. And here is the major issue I
> have...
> 
> ---- Beginning of a highly technical part :) ----
> 
> The linking problem:
>   I currently have to link the python library with the main gcompris.
> Why ? because all gcompris plugins are loaded without the dlopen option:
> RTLD_GLOBAL. 
> 
>   A quick answer to this problem will be: just add RTLD_GLOBAL to the
> dlopen options... but it doesn't work. Why  again?
> 
>   The more complete answer comes from the dlopen man page:
> 
> "Optionally, RTLD_GLOBAL may be or'ed with flag, in which case the
> external symbols defined in the library will be made available to
> subsequently loaded libraries."
> 
>   Nice, it will make the python symbols available for the dynamic loaded
> python modules (like gnome.canvs :) ). But the problem is that many
> plugins share the same symbols. So there are symbols conflict and this
> prevents gcompris to run !
> 
>   So what's the answer to this problem ? I think we'll have to re-open
> the plugin management debate ( it started already at fodem ). 

Let's go. There is no taboo in gcompris ;)

>  
>  What was discussed is the way Gcompris manages it's plugins: loading
> all plugins and keep them loaded for all the execution time.
> 
>  The advantage of this technique is:
>   - fast plugin switch
>   - be able to use a board identification process (is_our_board)
>  Disadvantages:
>   - Problems with subsequent library loads
>   - more memory consuption (and maybe CPU ?)
>   - Can't add a plugin at runtime ( maybe for developper only )

Agree.

>  
>  So I looked at the GCompris plugin handling code and pointed out some
> places to modify. Here is my "Load only one plugin at time HowTo fo
> GCompris"
> 
> **********************************************************************
> Load only one plugin at a time.
> -------------------------------
>    This will save some memory when executing gcompris and will avoid
> symbols
> conflicts (see previous change)
>    To do this change, we'll have to change the plugins. I propose to
> replace the function:
>      gboolean is_our_board (GcomprisBoard *gcomprisBoard);
>    by
>      char** get_handled_board_types(void);
>    This function will return an array of strings. Each string represents
> a handled board type.
>    Thoses strings will be copied and then stored in a HashTable. Each
> boardtype will be a key, and each value will be the corresponding plugin
> name (maybe we'll also store the plugins access path). This will give us
> a table like:
>    +-------------------------------------------------------------+
>    | "board_type_one"   | "/usr/lib/gcompris/libfirstplugin.so"  |
>    | "board_type_two"   | "/usr/lib/gcompris/libfirstplugin.so"  |
>    | "board_type_three" | "/usr/lib/gcompris/libsecondplugin.so" |
>    +-------------------------------------------------------------+
>    To do this future changes we will need to modify:
>     + All plugins source code to replace the is_our_board function
>     + Functions in the pluginenum.c
>     + The GcomprisBoard structure, in which we'll have to add the
> boardtype
> string.

You did mention is I remember at FOSDEM that we could make the
board_type match the plugin name. Why don't we simply do this ?
then the is_our_board is just deprecated and not replaced.
Would this work with your python plugin implementation.
If not, could we use the 'mode' option in the board xml file to specify
how the plugin should work.


>    A possible optimization will be to index the boradtypes at plugin
> loading time and to store this integer index into the GcomprisBoard
> structure in place of the board type string (this will save some memory
> and will avoid to compare string).
> **********************************************************************
> 
>   Those suggestions are not already applyable... and this is for me a
> major structure change in the gcompris code. So I think it will have to
> be targetted for some future gcompris release ( 2.5 ... 3.0 ... ?)
> 
I don't see it as a major issue. If we are sure that this is what we
need and it works, I can make the change in all the plugins if you want.

>   Also, the I'll keep the current linking process behaviour (python link
> with main gcompris program) until we find time to change this...
> 
>   To end, I think we'll have to take care of the RTLD_GLOBAL option,
> since plugin writers will maybe want to use some gcompris external
> libraries.
> 
> ---- End of the highly technical part ----
> 
> So I need some feedback !!!
> 
Here it is.

> To end the mail, the good news is that I got some gnome-python widgets
> working in gcompris... I have to write now the gcompris -> python glue
> code.
> 
Great.

> See you