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

[Bruno Coudoin]

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.

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

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

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.

What do you think ?

Bruno.