[gcompris-devel] Log Module for gcompris

Wed Jan 21 04:53:14 UTC 2004

Am Mittwoch 21 Januar 2004 01:44 schrieb Bruno Coudoin:
> Le mar 20/01/2004 à 15:26, Ralf Jardon a écrit :
> > Am Di, den 20.01.2004 schrieb stasZ um 10:41:
> > > Agree, i think that your comma separation is the form we should use.
> >
> > Yes, that´s my opinion too. The export/import possibilities with CSL are
> > a great advantage.
> >
> > > The first thing we should do before anything else is agree on the
> > > format of the logs and the description of the fields.
> >
> > Sounds good...
> >
> > > My suggestion of the fields:
> > > applicationname,date,starttime,host,user,level,number of excercise,
> > > result,endtime,comment,misc;
> >
> > OK, but in some boards the children can make different kinds of errors.
> >
> > For example in "smallnumbers":
> >
> > The goal of this board is counting the dots on a cube and typing the
> > appropriate key on the keyboard. An unexpected source of error here is
> > to type a letter and not a number. Another possibility is to type the
> > same wrong number again and again. I such case i need a logging output
> > that shows me the kind of errors and the frequency of errors.
> >
> > An example output for smallnumbers can look like this:
> >
> > date, app-name, host, level, starttime, endtime, usedtime,
> > detailed_result (e.g. 555tzh76568hijgh9), comment, misc;
> >
> > In the example above the detailed result shows the way of finding the
> > solution (the typed keys), the solution in this task was the "9". That
> > kind of logging makes the "result" cell redundant.
> >
> > Another (and IMHO better) way to log all possible errors is writing a
> > new line each key pressed. For example:
> >
> > date, app-name, host, starting_session;
> > date, app-name, level, usedtime, result_key(1), FALSE;
> > date, app-name, level, usedtime, result_key(2), FALSE;
> > date, app-name, level, usedtime, result_key(3), FALSE;
> > date, app-name, level, usedtime, result_key(4), TRUE;
> > date, app-name, host, ending_session, comment;
> >
> > In that case the starttime and endtime are redundant, we have a starting
> > and ending line. The great  advantage in this kind of logging is to have
> > the time between the key pressing (the thinking time of the chindren)
> > so i would prefer this kind of logging. In fact it is a key-logging :-)
>
> I see your point but it maybe hard to read a such file with so many
> entries. We'd better stick to a one line by PASS/FAILL event. We could
> meet your need by adding a keylog field the could be defined by
> something like KA/2:KB/10 which would mean Key 'A' after 2 seconds and
> Key 'B' after 10 seconds. We could track M1 for mouse button 1 but you
> won't know where the click was.
> Would this be fine for you?

Yes, of course. It looks very good...
But we should think about a standard for a keylog field. I suggest a variant 
of your example above:

...,a/2:B/5:8/2,...

"a" is the key pressed, the slash is the seperator between the pressed key (an 
ascii charakter) and the time, "2" is the used time in seconds, the colon is 
the seperator between two keys... a "K" for "Key" in in my opinion not 
necessary.

> It's not complex for us since all keys events are catched by gcompris
> core first, then dispatched to boards.

Fine...

>
> > Logging the user name is IMHO not necessary because i suppose in
> > practice each children will use it´s own Linux-login. The logfile should
> > be located in /home/CHILD/.gcompris_log or better in
> > /home/CHILD/.CHILD_gcompris_log because i have 26 children in the
> > kindergarten and different logfile-names will make the use simpler.
>
> So you need the username. You can get rid of it in the file but you will
> be in trouble if you merge 2 files. You loose the user then.
> It's better to keep it for this reason.

Agree

Bye
Ralf
>
> > Bye
> > Ralf
> >
> > > Stas Z
> > >
> > > "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
> >
> > -------------------------------------------------------
> > 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
>
> -------------------------------------------------------
> 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

-- 
-------------------------------------------------------------------------------
Ralf Jardon, Seminar für Lernbehindertenpädagogik
Universität zu Köln, Klosterstr. 79b, D-50931 Köln
Tel. : +49-221-470-5536, Fax  : +49-221-470-2167, Büro : 330
       			 * pgp/gpg Key available *
-------------------------------------------------------------------------------