[GCompris-devel] GCompris-devel Digest, Vol 17, Issue 17

Sat Mar 19 20:15:04 UTC 2016

Hi
As far as I've understood Emmanuel Charruau's suggestion, adding a third
level would make it more scalable and would give more freedom (in sense of
app size and features) to the user.

I also wished to ask that could it be considered as a probable GSoC'16
project?

Thanks

On Sun, Mar 20, 2016 at 1:03 AM, <gcompris-devel-request at kde.org> wrote:

> Send GCompris-devel mailing list submissions to
>         gcompris-devel at kde.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.kde.org/mailman/listinfo/gcompris-devel
> or, via email, send a message with subject or body 'help' to
>         gcompris-devel-request at kde.org
>
> You can reach the person managing the list at
>         gcompris-devel-owner at kde.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of GCompris-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: Introduction + GCompris Idea Discussion (
> 
> Emmanuel Charruau)
>    2. Re: Introduction + GCompris Idea Discussion (Emmanuel Charruau)
>    3. Re: Introduction + GCompris Idea Discussion (JAZEIX Johnny)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 19 Mar 2016 14:49:34 +0100
> From: Emmanuel Charruau <echarruau at gmail.com>
> To: Bruno Coudoin <bruno.coudoin at gcompris.net>
> Cc: GCompris Devel <gcompris-devel at kde.org>
> Subject: Re: [GCompris-devel] Introduction + GCompris Idea Discussion
> Message-ID:
>         <
> CA+jbWcF6NdNksHm9H-vRnj0Au3bzcpqh+vB3+e2wbrDCVcSadg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Sat, 19 Mar 2016 20:28:14 +0100
> From: Emmanuel Charruau <echarruau at gmail.com>
> To: Bruno Coudoin <bruno.coudoin at gcompris.net>
> Cc: GCompris Devel <gcompris-devel at kde.org>
> Subject: Re: [GCompris-devel] Introduction + GCompris Idea Discussion
> Message-ID:
>         <
> CA+jbWcG3_ziao0j9EFQAuzJoua9VpUSYMfV9KsXLpZSPYA5Gig at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Sat, 19 Mar 2016 20:33:37 +0100
> From: JAZEIX Johnny <jazeix at gmail.com>
> To: gcompris-devel at kde.org
> Subject: Re: [GCompris-devel] Introduction + GCompris Idea Discussion
> Message-ID: <56EDA991.1070701 at gmail.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> 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.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> GCompris-devel mailing list
> GCompris-devel at kde.org
> https://mail.kde.org/mailman/listinfo/gcompris-devel
>
>
> ------------------------------
>
> End of GCompris-devel Digest, Vol 17, Issue 17
> **********************************************
>

-- 
It is not your qualifications but your exposure in life that makes you who
you are.
Devendra Vyas
Final Year,Comp. Science
B.tech , The LNMIIT
Jaipur(Raj.)
Ph no. (+91)9460053732
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20160320/4bdd493a/attachment-0001.html>