[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