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

[Olivier Samyn]

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)

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.

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

  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 !!!

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.

See you

-- 
Ir. Olivier Samyn <osamyn at ulb.ac.be>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcompris2.3-gnome2.2.diff
Type: text/x-patch
Size: 885 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20030220/213f66fc/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20030220/213f66fc/attachment.sig>