[GCompris-devel] Introduction + GCompris Idea Discussion

Emmanuel Charruau echarruau at gmail.com
Sat Mar 19 19:28:14 UTC 2016


Hi again,

A furthur idea came to me. If we create a third level depth like explained
in my previous email, it would also be good to be able to tag these third
level.
Let's take again our lang activity.
The same set of image could be interesting to teach kids from 6-8 and at
the same time only speaking about nature, we should be able to tag them as
"kids from 6-" and "nature".

Is that a good idea?

Regards,

Emmanuel



2016-03-19 14:49 GMT+01:00 Emmanuel Charruau <echarruau at gmail.com>:

> 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?
>
>
> Regards,
>
> Emmanuel
>
> ps: I would love to have this option for my grammatical activity, as
> grammar contains a huge quantity of different competences.
>
>
>
> 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>
>> 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)
>>
>> If we can do this we and this gives good results we can go further to
>> include more requirements like:
>>
>> - Inter Activity dependencies
>> - Core API level (versioning of activities versus the core)
>> - 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.
>>
>> Bruno.
>>
>> _______________________________________________
>> 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/aef53cb2/attachment.html>


More information about the GCompris-devel mailing list