Generaly speaking, all C gcompris_xxx functions are wrapped to a corresponding gcompris.xxx function; parameters and return types remains the same. Some structures have also been wrapped. See below particular notes about this.

The wrapped functions are divided into packages. Every package correponds to a gcompris header file (gameutil.h, score.h, ...)

For each package/header not all functions have been wrapped. Only functions that are used/usefull for plugins are wrapped.

Notice also that not all functions have been tested (with time and new python plugins implemented they will be, but...). The wrappers have been written, they compiles, but there is no warranty on their behaviour... I you find a bug report it!

Each board written in python must contains a class which name is "Gcompris_xxx" where xxx is the name of the board. Let's take an example: I made a gcompris board written in python and called "pythontest".

For this board there is a gcompris pythontest.xml file containing "pythontest" for the board name and "pythonboard" for the board type. There's also a pythontest.py file containing the board code. And to finish, this file contains a "Gcompris_pythontest" class definition which in turns contains the needed gcompris board functions.

The class defined in the python board must contains the following methods:

For the method role and use, please consult the sample pythontest.py board and other C boards.

An instance of this structure in Python will act like an instance of the C one. Here a some Python call samples:

...
  gcomprisBoard.level = 1
  gcomprisBoard.maxlevel = 1
...
  gcompris.bar_start(gcomprisBoard.canvas)
...

Here are the Python structure member name and type, and a note indicating if the attribute is readeable and/or writable.