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

[Olivier Samyn]

Le jeu 20/02/2003 à 20:02, Bruno Coudoin a écrit :

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

What about plugins that can play multiple board types ? 
(I don't have and example but... why not?)
And also, what about bad installations ... where some plugins are not
available but the xml files are ? 

I think the identification process is good. So I thinked more about this
issue and I found a better solution...

1) change the is_our_board behaviour

let's for sample replace the click game is_our_board with:

clickgame_is_our_board (GcomprisBoard *gcomprisBoard)
{
  if (gcomprisBoard)
    {
      if(g_strcasecmp(gcomprisBoard->type, "clickgame")==0)
        {
          return TRUE;
        }
    }
  return FALSE;
}
 
(I removed the set plugin entry)

2) add a pluginpath into the GcomprisBoard structure

3) Add a startup code that:
 - Loads all available boards (xml)
 - For each available plugin:
   - Load it
   - Check each not undentified board with the plugin is_our_board
function. If it returns true, set the board's pluginpath to the plugin's
path.
   - Unload it
 - Remove unidentified boards.
  
 Now what we have are GComprisBoard structures without the "plugin"
member set. So when gcompris switch from one board to another, the
switching function will have to:
 - unload the previous_board plugin
 - set the previous_board plugin member to NULL
 - load the new board plugin using the pluginpath member
 - set the new board plugin member to the loaded plugin.


Thoses changes will only ask to:
- remove some lines in the plugins code (30'minutes :) )
- implement the board checking process
- check/modify some functions like the board_play one.

This is not really a quick change and I don't need it for now...

Maybe I'll get time to do it when I've finished the python plugin... or
if someone have time to do it...

Also, I don't analysed the current boards/plugin loading process so I
can't really say if it will be easy to implement this new behaviour...

Isn't it a better idea than just hardcoding somewhere the plugin name ?


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