[GCompris-devel] Introduction + GCompris Idea Discussion

[Emmanuel Charruau]

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/e24dc927/attachment.html>