[gcompris-devel] Some questions/suggests....

[bruno]

Le ven 14/02/2003 à 17:18, Olivier Samyn a écrit :
> Hi all,
> 
> I began yesterday to code the python bingings for gcompris.
> 
> I decided to create a special plugin (board type) that will handle the
> python's calls. I decided that the true board code will be placed in a
> python file (*.py) having the same name as the board's name attribute.
> 
> For example, in the board xml file you put: 
> ...
> <GCompris>
>  <Board 
>        name="myboard"
>        type="pythonboard"
>        ...
> ...
> 
> 
> The python plugin will look for a file named "myboard.py" and execute
> it. Simple isn't it ?
> 
Yes, that works for me.

> But here comes the first question: Is this approach valid ? Does anyone
> have remarks ?
> 
No remarks for now, it will break nothing I can think of.

> And following, the secod question: Where does I have to put the pythons
> files ? I think I have two possible options: somewhere in the
> $prefix/lib/gcompris directory or in the $prefix/share/gcompris.
> 
> For my part, I prefer the first solution since the python code can be
> viewed as an executable code like the plugins(with a special type). So I
> thinks I'll put the *.py files in $prefix/lib/gcompris/python 
> 
> What about this option ?
> 
Both make sense, let's go for $prefix/lib/gcompris/python like you
propose.

> After those architectures questions, here are some gcompris questions.
> I've seen there are four unused plugins functions. What about those
> functions ?  what are their behaviour ? is there some examples
> illustrating their use ? Does I have to create a python wrapper for them
> or not ?
> 
> The functions I'm speaking about are (copying from plugin.h):
>   typedef void (*GcomprisConfig)(); // and it's use in the plugin struct
This is used in conjunction with the toolbar
gcompris_bar_set(GCOMPRIS_BAR_CONFIG)
It can be used by activities that need or can be configured. This way
the used enter the boards configure options. It is used today by the
menu board only and starts the general gcompris configuration box.
We have to keep it

>   void (*about) (void);         /* Show the about box */
It as never been used and should not be used. We now have all the manual
including credits in the xml board file.
It should be removed.  

>   void (*configure) (void);     /* Show the configuration dialog */
> 
OK, here I see the point. This is twice in the API. One should be
removed.

I suggest to remove the lines :
void (*about) (void);		/* Show the about box */
void (*configure) (void);	/* Show the configuration dialog */
from plugin.h

Now when is the best time to do this ? I assume you prefer to make your
implementation on a clean API.
Please, tell me when to do it, and I will do it.

> 
> After all those questions, here are some suggests:
> - Remove the .xml.in an makefiles from the installation process. I got
> all those files in my $prefix/share/gcompris directory.

I agree but I don't have them in my case after a make install.
We have the problem with these files being present in the tar ball (make
dist). I have already fixed that in the last gcompris/Makefile.am 

> - Some gnome 1.x macros or constructs are use in the configure file.
> Replacing those with pkg-config macros will be a good idea (since
> gcompris uses gnome 2.x) Especially for the libxml checks.
> 
OK, please fix it if you know the correct answer.

> That's all for today...
> 
> I'm waiting for your feedback...
> 
> -- 
> Ir. Olivier Samyn <osamyn at ulb.ac.be>
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> gcompris-devel mailing list
> gcompris-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gcompris-devel
>