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

[Johnny Jazeix]

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.

>
> 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']}
> }
>

Storing missing words instead of done is a good idea as it will
decrease the size of the file when the child will play.
For the option to choose, let's do the easier to encode/decode.

> (Not sure we can do multi lines but we can do json on one line)

We can store arrays so it should be feasible.

>
> 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.

Johnny

> What do you think ?
>
> Bruno.
> _______________________________________________
> GCompris-devel mailing list
> GCompris-devel at kde.org
> https://mail.kde.org/mailman/listinfo/gcompris-devel