[GCompris-devel] saving the progress for Lang activity.

[Bruno Coudoin]

Le 07/07/2015 10:38, Johnny Jazeix a écrit :
> Hi,
>
> 2015-07-07 2:40 GMT+02:00 Bruno Coudoin <bruno.coudoin at gcompris.net>:
>> Hi,
>>
>> I have read the different options in this tread.
>>
>> I prefer to exclude the most 'complex' possibilities like having a
>> database or an extra file per activity. I am afraid it would annoy us to
>> have some legacy when designing the administration module.
> In fact, it was one file for all the stats in order to differentiate
> stats from config but I agree that we should not add non needed
> dependency.
I agree that it would make sense to separate this in 2 files (config and
stats). It would make the code a little bit more complex to handle 2
files and I am not sure it is worth doing it. Let's stick to the YAGNI
rule (https://fr.wikipedia.org/wiki/YAGNI).
>> Let's clearly separate the 2 concepts, generic activity progress and
>> specific one.
>>
>> For the generic one, we can use our config file and add a group
>> [progress] like we did for favorite. We have to extend the activity
>> model to support this value.
>>
>> For the specific one, we already use our config file for that with a
>> section by activity. We have a nive API to store and retrieve values
>> there with void ApplicationSettings::saveActivityConfiguration(const
>> QString &activity, const QVariantMap &data)
>>  and QVariantMap ApplicationSettings::loadActivityConfiguration(const
>> QString &activity).
>>
>> One idea for the lang activty if to create a new specific section by
>> locale. For example the config file could look like this:
>>
>> Option 1:
>> [lang]
>> locale=system  (The specific configuration as we have it today)
>>
>> [lang-fr] (The specific configuration to track progress in french with
>> values in json)
>> object={'favorite': False, 'progress': 0.5, 'missed_words': ['table',
>> 'chaise']}
>>
>> Option 2:
>> [lang]
>> locale=system  (The specific configuration as we have it today)
>> object-fr={'favorite': False, 'progress': 0.5, 'missed_words': ['table',
>> 'chaise']}
>>
>> Option 3:
>> [lang]
>> locale=system  (The specific configuration as we have it today)
>> object={
>>  'en': {'favorite': False, 'progress': 0.5, 'missed_words': ['table',
>> 'bicycle']}
>>  'fr': {'favorite': False, 'progress': 0.5, 'missed_words': ['table',
>> 'chaise']}
>> }
>>
Looking again at it, I don't like the third option. What we can imagine
is that at each passed level there will be a write or update of a single
line the config file. In teacher mode this line could be send to the
teacher console as well (or instead) of being saved locally. In a
classroom where they don't log children, it does not make sense to track
progress. In all case we have to add an option do disable and clear
progress.
>
>> This way we keep a single configuration file, even if it grows, It is so
>> easy to parse, I believe we have time before it becomes an issue. We let
>> activities have their own data in it, they must support getting old
>> values in an older format if they make some evolutions in it.
>>
>> As it is centralized and forces activities to format their configuration
>> in key/values, we could in the future admin quiet easily read, publish
>> and share all these specific part. For deciphering the values, we would
>> need the help of the activity itself on the administration side. But
>> whatever we choose to store the data we will have to do this.
>>
> There probably exist some API to parse ini files, we just have to
> specify which tags we don't parse.
> For decoding tags, we can probably add, for specific activities, an
> enum telling how to decode and parse it on the admin side.
>
We already parse this file and have an API for that. What we miss is to
add the progress information in the activity model. We should accept
levels as being ascii, no necessarily numbers. In general it will be
number but for lang ascii name are easier. We can also say that the
progress is on each level, not on the activity. This way we can know a
children passed level 3 but not the 2. The general activity level can be
calculated and never stored.

For the teacher, we can just create a clear text string that will be
translated and that explains what's going on.  For example: difficulty
with words: table, chaise. This way we can keep the protocol activity
independent and makes it easy to create a teacher console.

Bruno.