[GCompris-devel] Introduction + GCompris Idea Discussion

Sat Mar 19 21:07:33 UTC 2016

Hi,

Johnny's idea "This way, you can also only download datasets for some
language." gave me an idea, maybe he meant it by the way.
If we are able to download special exercices in a list, we can if we are in
french configuration download english exercices in order to learn or
improve our english!
That would be very cool for foreign language teachers for example.

Emmanuel

2016-03-19 20:33 GMT+01:00 JAZEIX Johnny <jazeix at gmail.com>:

> Hi,
>
> On 03/19/16 14:49, Emmanuel Charruau wrote:
>
> Hi,
>
> If we go this way, and since we are reworking the architecture, could we
> not implement a third level depth?
> Let me give you an example.
> We want to provide more specialised vocable classes for the lang activity
> (the one to learn vocable).
> We could have the following tree
> vocable
>   - kids 5-6
>   - kids 7-9
>   - etc
> but also
>
>   - nature
>   - geography
>
> etc.
>
> User would be able to first select the lang activity, then in lang
> activity select for example "kids 5-9" and "nature" but not geography as he
> does not want to download these classes.
>
> What do you think?
>
>
> Basically it's adding downloadable datasets per activity?
>
>
> Regards,
>
> Emmanuel
>
> ps: I would love to have this option for my grammatical activity, as
> grammar contains a huge quantity of different competences.
>
> This way, you can also only download datasets for some language.
>
>
>
> 2016-03-19 9:49 GMT+01:00 Bruno Coudoin <bruno.coudoin at gcompris.net>:
>
>>
>>
>> Le 18/03/2016 22:31, Devendra Vyas a écrit :
>>
>> Hi!
>> Congratulations for getting selected in GSoC'16
>>
>> I am Devendra Vyas, fourth year undergrad studying Computer Science at
>> The LNMIIT, Jaipur. I've a decent background in algorithms and
>> data-structures, qualified for ACM-ICPC Regionals. I'm new to open source
>> contribution and recently started contributing to GNU-Mailman(Postorius, as
>> of now).
>>
>> This year at conf.KDE I had a chat with Bruno Coudoin about reducing the
>> size of the android app for the end user by providing two options -
>> 1) Full download (Nothing new here, currently app works this way)
>> 2) Providing an option to selectively download any activity
>> I had a brief talk with Sagar and as far I have understood, basically the
>> core directory is to be divided into categories as in, one part would
>> contain basic scripts needed for any activity to render and other part
>> would comprise of various scripts segregated in different directories may
>> be for each activity.
>> Now when a user downloads, we would just provide with the basic scripts
>> needed for running any app. If the user opts for a full download then all
>> the data(from both Activities and Core directory) will be pushed. Else, if
>> he/she selects a particular activity we'll only push corresponding Activity
>> directory and its corresponding script directory from the core.
>>
>> It would be really great to have your views upon it.
>>
>>
>> Hi,
>>
>> Glad to see you here, it was great fun talking about that with you in
>> Jaipur.
>>
>> As Johnny found out we already started this discussion a while ago in
>> https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html?
>>
>> If we go further on that I would propose the following:
>>
>> - Build an additional <activity>-info.rcc that contains the
>> ActivityInfo.qml and the icon.
>> - Remove the ActivityInfo.qml and the icon from full activity rcc
>> - Make GCompris load the menu from the <activity>-info.rcc instead of the
>> full rcc
>> - Load the full rcc on entering the activity (or download it if we don't
>> have it locally)
>>
>>
> We also have to take care about paying activities. If the user only wants
> one paying activity, will he pay for all?
>
> If we can do this we and this gives good results we can go further to
>> include more requirements like:
>>
>> - Inter Activity dependencies
>>
> Won't it be needed? I mean, if user want to download an extended activity
> (erase_2clic, chronos...), he will need the activities they are based on
> (erase, babymatch...).
>
> - Core API level (versioning of activities versus the core)
>>
>
> It will be needed anyway because if we have some issues with one activity,
> it will be nice to know which version :).
>
> - User interface option to download all the activities in one go
>> - Adding new activities server side without reinstalling GCompris (means
>> the flat list of activities in activities.rcc must be downloadable)
>>
>> Devendra, if the GCompris team agree on this proposal, it would be nice
>> to see you working on it.
>>
>
> I have nothing against it if you are motivated to do it :).
>
>
>> Bruno.
>>
>> _______________________________________________
>> GCompris-devel mailing list
>> GCompris-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/gcompris-devel
>>
>>
>
>
> _______________________________________________
> GCompris-devel mailing listGCompris-devel at kde.orghttps://mail.kde.org/mailman/listinfo/gcompris-devel
>
> Johnny
>
>
> _______________________________________________
> GCompris-devel mailing list
> GCompris-devel at kde.org
> https://mail.kde.org/mailman/listinfo/gcompris-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20160319/2cbdfdfb/attachment.html>