[GCompris-devel] Introduction + GCompris Idea Discussion

JAZEIX Johnny jazeix at gmail.com
Sat Mar 19 19:33:37 UTC 2016


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 
> <mailto: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 <mailto:GCompris-devel at kde.org>
>     https://mail.kde.org/mailman/listinfo/gcompris-devel
>
>
>
>
> _______________________________________________
> GCompris-devel mailing list
> GCompris-devel at kde.org
> https://mail.kde.org/mailman/listinfo/gcompris-devel
Johnny

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20160319/9a2b7aab/attachment-0001.html>


More information about the GCompris-devel mailing list