[gcompris-devel] Generic Reporting tool at classroom level

stasZ stas at linux.isbeter.nl
Sun Nov 9 02:35:20 UTC 2003


On 2003.11.08 15:15, Bruno Coudoin wrote:
> 
> As I already mentionned, we need to set up a tool that will help
> teacher
> use gcompris in a classroom. Currently, there is no way to to this  
> and
> following 10 kids on gcompris is too hard.

First of all, i've already have a monitor plugin under development
in childsplay, so all the comments and ideas i make are based on this  
tool. It
doesn't much more then login and parsing permissions, yet.

I will send it as a attachment to Bruno Coudoin because i know
he has everything installed to run it ;-).
If any body else wants it, just let me know.

> Bruno Patin (Yes, another Bruno) proposed to wokd on this.
> 
> In this mail, i'll try to give some idea on what we need and some  
> idea
> to achieve that.
> 
> First, we can easily include in gcompris a call to a sucess/fail
> recording based on the bonus API. The bonus API is the one a board
> call
> when it's a done or a fail. This means, we don't need to change all
> the
> boards to do this, just improve the current bonus system.

You should also consider to put the "raw" result in a XML format
in a temp file ,which should be cleared at exit, so that there's always
a possibility for users/teachers to handle the results with there own  
tools.

> Then on the end user level we need to be abble to access to the
> classroom result. A web interface could be fine but its should also
> work
> in a 'parent' environment in which a web interface could be too heavy
> to
> set up.

I think its better to send the results by email to avoid all kinds of  
security
issues with web servers. Again if the result/report is in
XML/openoffice format then it could be send as a attachment to any  
place on
this world and handled by any application.
Internally it could also be put in plain text and pasted in the mail  
body.

> The interface should answer to the question who did what and when in
> gcompris.
> 
> The system we propose should be independant of gcompris. We should be
> able to propose kdeedu, childsplay, the python games developpers, and
> other free school developpers to leverage and integrate it in their
> own
> software (I copying the most active developpers I know)

That's the future (IMHO), it should be as platform independant as  
possible.
Also as speed is not a issue, because only when the user logs out/stops  
the
tool gets a standarized list/file to handle, so it could perhaps be a  
stand
alone apllication.

> We are facing a problem with login. In some environment, we don't  
> have
> a
> login per user. It could be necessary to create in gcompris a pseudo
> login (profile) to record the user name.

The childsplay monitor plugin handles users login and  sets permissions
based on a rc file, also there's a possibility to put users in groups.
(the whole idea is based on Linux permissions)

The monitor plugin also handles the actual login stuff and ask for a  
name and
let the child choose a nice icon to create a "name-badge"
which could be printed out (in the future:-)
The presents of the monitor plugin changes the workings childsplay, by
giving control to the monitor (when needed).

> That's all I have think of. Feel free to discuss the what and how to
> do
> this on this list so that Bruno Patin will get most of the  
> requirement
> early in the development. If anybody want to join, it's would be
> great,
> there is definitly room for others.
>

Well, apart from the Gcompris side of things i"ll suggest we combine  
our
efforts at much as possible, so hereby i sign up :-)

Stas Z




More information about the Gcompris-devel mailing list