[gcompris-devel] Log Module for gcompris

Mon Jan 19 16:12:02 UTC 2004

I just commited the first implementation of the traces in gcompris.
The log is written to a file named .gcompris.log in the home directory.

The API is:

Only gcompris_log_set_reason is generaly needed for boards. In fact,
start and end are managed by gcompris core. For the end, it relies on
the bonus API so the boards that do not use it 

/* gcompris internal only */
void gcompris_log_start (GcomprisBoard *gcomprisBoard); 

/* Use it to tell the teacher where the kid failed */
void gcompris_log_set_reason (GcomprisBoard *gcomprisBoard, gchar
*comment); 

/* Do not use it if you use the bonus API in your board */
void gcompris_log_end (GcomprisBoard *gcomprisBoard, gchar *status);

Here is an example of a failed log in reading
mar jan 20 00:38:12 CET
2004,bruno.maison,bcoudoin,readingv,1,1,FAILED,14.000000,The word to
find was 'vit'

Ralf, it's already better I think than your implementation (thanks for
your help, I took part of your code ;).

Stasz, on your side, what do you think of it. Is this ok for childsplay
or we need something else.
I though we could at the application name in the format so that if we
want to have a share single trace file on a host, it would work.

Next, I will look at a simple trace viewer. Basically, I think of a
table in which you can filter. It should be enough for a teacher to find
it's kids results. A button will let him reset the log when think
becomes too old and huge.

I don't plan to work on XML, OO.org or remote sharing of this trace for
now. Let's go step by step and see if we really meet our users with this
feature.

Bruno.

Le lun 19/01/2004 à 09:07, stasZ a écrit :
> On 2004.01.19 02:55, Bruno Coudoin wrote:
> 
> > That's a good oportunity to think about what we need here (stasZ,
> > still
> > there ?).
> 
> Yep,
>  
> > With you code, we monitor the time in each board/level. That's a good
> > start but to be usefull, we need some sucess/failure data and a
> > comment
> > on what failed so that a teacher can easily read it.
> 
> I paste a bit of a earlier discussion between Bruno C and me, because i
> believe the solution is still the same :-)
> 
> the ">" pieces are from Bruno, the rest are my former replies:
> 
> ####### Begin old discussion ################
> 
> > 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 :-)
> 
> 
> 
> --
> "There are only 10 types of people in this world:
>  Those who understand binary, and those who don't."
>  
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> gcompris-devel mailing list
> gcompris-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gcompris-devel
> 