<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Hi<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">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.<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br>I also wished to ask that could it be considered as a probable GSoC'16 project? <br><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Thanks<br> </div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 20, 2016 at 1:03 AM, <span dir="ltr"><<a href="mailto:gcompris-devel-request@kde.org" target="_blank">gcompris-devel-request@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send GCompris-devel mailing list submissions to<br>
<a href="mailto:gcompris-devel@kde.org">gcompris-devel@kde.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://mail.kde.org/mailman/listinfo/gcompris-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/gcompris-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:gcompris-devel-request@kde.org">gcompris-devel-request@kde.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:gcompris-devel-owner@kde.org">gcompris-devel-owner@kde.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of GCompris-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Introduction + GCompris Idea Discussion (<div class="gmail_default" style="font-family:trebuchet ms,sans-serif;display:inline"></div>Emmanuel Charruau)<br>
2. Re: Introduction + GCompris Idea Discussion (Emmanuel Charruau)<br>
3. Re: Introduction + GCompris Idea Discussion (JAZEIX Johnny)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sat, 19 Mar 2016 14:49:34 +0100<br>
From: Emmanuel Charruau <<a href="mailto:echarruau@gmail.com">echarruau@gmail.com</a>><br>
To: Bruno Coudoin <<a href="mailto:bruno.coudoin@gcompris.net">bruno.coudoin@gcompris.net</a>><br>
Cc: GCompris Devel <<a href="mailto:gcompris-devel@kde.org">gcompris-devel@kde.org</a>><br>
Subject: Re: [GCompris-devel] Introduction + GCompris Idea Discussion<br>
Message-ID:<br>
<<a href="mailto:CA%2BjbWcF6NdNksHm9H-vRnj0Au3bzcpqh%2BvB3%2Be2wbrDCVcSadg@mail.gmail.com">CA+jbWcF6NdNksHm9H-vRnj0Au3bzcpqh+vB3+e2wbrDCVcSadg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
If we go this way, and since we are reworking the architecture, could we<br>
not implement a third level depth?<br>
Let me give you an example.<br>
We want to provide more specialised vocable classes for the lang activity<br>
(the one to learn vocable).<br>
We could have the following tree<br>
vocable<br>
- kids 5-6<br>
- kids 7-9<br>
- etc<br>
but also<br>
<br>
- nature<br>
- geography<br>
<br>
etc.<br>
<br>
User would be able to first select the lang activity, then in lang activity<br>
select for example "kids 5-9" and "nature" but not geography as he does not<br>
want to download these classes.<br>
<br>
What do you think?<br>
<br>
<br>
Regards,<br>
<br>
Emmanuel<br>
<br>
ps: I would love to have this option for my grammatical activity, as<br>
grammar contains a huge quantity of different competences.<br>
<br>
<br>
<br>
2016-03-19 9:49 GMT+01:00 Bruno Coudoin <<a href="mailto:bruno.coudoin@gcompris.net">bruno.coudoin@gcompris.net</a>>:<br>
<br>
><br>
><br>
> Le 18/03/2016 22:31, Devendra Vyas a écrit :<br>
><br>
> Hi!<br>
> Congratulations for getting selected in GSoC'16<br>
><br>
> I am Devendra Vyas, fourth year undergrad studying Computer Science at The<br>
> LNMIIT, Jaipur. I've a decent background in algorithms and data-structures,<br>
> qualified for ACM-ICPC Regionals. I'm new to open source contribution and<br>
> recently started contributing to GNU-Mailman(Postorius, as of now).<br>
><br>
> This year at conf.KDE I had a chat with Bruno Coudoin about reducing the<br>
> size of the android app for the end user by providing two options -<br>
> 1) Full download (Nothing new here, currently app works this way)<br>
> 2) Providing an option to selectively download any activity<br>
> I had a brief talk with Sagar and as far I have understood, basically the<br>
> core directory is to be divided into categories as in, one part would<br>
> contain basic scripts needed for any activity to render and other part<br>
> would comprise of various scripts segregated in different directories may<br>
> be for each activity.<br>
> Now when a user downloads, we would just provide with the basic scripts<br>
> needed for running any app. If the user opts for a full download then all<br>
> the data(from both Activities and Core directory) will be pushed. Else, if<br>
> he/she selects a particular activity we'll only push corresponding Activity<br>
> directory and its corresponding script directory from the core.<br>
><br>
> It would be really great to have your views upon it.<br>
><br>
><br>
> Hi,<br>
><br>
> Glad to see you here, it was great fun talking about that with you in<br>
> Jaipur.<br>
><br>
> As Johnny found out we already started this discussion a while ago in<br>
> <<a href="https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html" rel="noreferrer" target="_blank">https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html</a>><br>
> <a href="https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html" rel="noreferrer" target="_blank">https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html</a>?<br>
><br>
> If we go further on that I would propose the following:<br>
><br>
> - Build an additional <activity>-info.rcc that contains the<br>
> ActivityInfo.qml and the icon.<br>
> - Remove the ActivityInfo.qml and the icon from full activity rcc<br>
> - Make GCompris load the menu from the <activity>-info.rcc instead of the<br>
> full rcc<br>
> - Load the full rcc on entering the activity (or download it if we don't<br>
> have it locally)<br>
><br>
> If we can do this we and this gives good results we can go further to<br>
> include more requirements like:<br>
><br>
> - Inter Activity dependencies<br>
> - Core API level (versioning of activities versus the core)<br>
> - User interface option to download all the activities in one go<br>
> - Adding new activities server side without reinstalling GCompris (means<br>
> the flat list of activities in activities.rcc must be downloadable)<br>
><br>
> Devendra, if the GCompris team agree on this proposal, it would be nice to<br>
> see you working on it.<br>
><br>
> Bruno.<br>
><br>
> _______________________________________________<br>
> GCompris-devel mailing list<br>
> <a href="mailto:GCompris-devel@kde.org">GCompris-devel@kde.org</a><br>
> <a href="https://mail.kde.org/mailman/listinfo/gcompris-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/gcompris-devel</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.kde.org/pipermail/gcompris-devel/attachments/20160319/e24dc927/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.kde.org/pipermail/gcompris-devel/attachments/20160319/e24dc927/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sat, 19 Mar 2016 20:28:14 +0100<br>
From: Emmanuel Charruau <<a href="mailto:echarruau@gmail.com">echarruau@gmail.com</a>><br>
To: Bruno Coudoin <<a href="mailto:bruno.coudoin@gcompris.net">bruno.coudoin@gcompris.net</a>><br>
Cc: GCompris Devel <<a href="mailto:gcompris-devel@kde.org">gcompris-devel@kde.org</a>><br>
Subject: Re: [GCompris-devel] Introduction + GCompris Idea Discussion<br>
Message-ID:<br>
<<a href="mailto:CA%2BjbWcG3_ziao0j9EFQAuzJoua9VpUSYMfV9KsXLpZSPYA5Gig@mail.gmail.com">CA+jbWcG3_ziao0j9EFQAuzJoua9VpUSYMfV9KsXLpZSPYA5Gig@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi again,<br>
<br>
A furthur idea came to me. If we create a third level depth like explained<br>
in my previous email, it would also be good to be able to tag these third<br>
level.<br>
Let's take again our lang activity.<br>
The same set of image could be interesting to teach kids from 6-8 and at<br>
the same time only speaking about nature, we should be able to tag them as<br>
"kids from 6-" and "nature".<br>
<br>
Is that a good idea?<br>
<br>
Regards,<br>
<br>
Emmanuel<br>
<br>
<br>
<br>
2016-03-19 14:49 GMT+01:00 Emmanuel Charruau <<a href="mailto:echarruau@gmail.com">echarruau@gmail.com</a>>:<br>
<br>
> Hi,<br>
><br>
> If we go this way, and since we are reworking the architecture, could we<br>
> not implement a third level depth?<br>
> Let me give you an example.<br>
> We want to provide more specialised vocable classes for the lang activity<br>
> (the one to learn vocable).<br>
> We could have the following tree<br>
> vocable<br>
> - kids 5-6<br>
> - kids 7-9<br>
> - etc<br>
> but also<br>
><br>
> - nature<br>
> - geography<br>
><br>
> etc.<br>
><br>
> User would be able to first select the lang activity, then in lang<br>
> activity select for example "kids 5-9" and "nature" but not geography as he<br>
> does not want to download these classes.<br>
><br>
> What do you think?<br>
><br>
><br>
> Regards,<br>
><br>
> Emmanuel<br>
><br>
> ps: I would love to have this option for my grammatical activity, as<br>
> grammar contains a huge quantity of different competences.<br>
><br>
><br>
><br>
> 2016-03-19 9:49 GMT+01:00 Bruno Coudoin <<a href="mailto:bruno.coudoin@gcompris.net">bruno.coudoin@gcompris.net</a>>:<br>
><br>
>><br>
>><br>
>> Le 18/03/2016 22:31, Devendra Vyas a écrit :<br>
>><br>
>> Hi!<br>
>> Congratulations for getting selected in GSoC'16<br>
>><br>
>> I am Devendra Vyas, fourth year undergrad studying Computer Science at<br>
>> The LNMIIT, Jaipur. I've a decent background in algorithms and<br>
>> data-structures, qualified for ACM-ICPC Regionals. I'm new to open source<br>
>> contribution and recently started contributing to GNU-Mailman(Postorius, as<br>
>> of now).<br>
>><br>
>> This year at conf.KDE I had a chat with Bruno Coudoin about reducing the<br>
>> size of the android app for the end user by providing two options -<br>
>> 1) Full download (Nothing new here, currently app works this way)<br>
>> 2) Providing an option to selectively download any activity<br>
>> I had a brief talk with Sagar and as far I have understood, basically the<br>
>> core directory is to be divided into categories as in, one part would<br>
>> contain basic scripts needed for any activity to render and other part<br>
>> would comprise of various scripts segregated in different directories may<br>
>> be for each activity.<br>
>> Now when a user downloads, we would just provide with the basic scripts<br>
>> needed for running any app. If the user opts for a full download then all<br>
>> the data(from both Activities and Core directory) will be pushed. Else, if<br>
>> he/she selects a particular activity we'll only push corresponding Activity<br>
>> directory and its corresponding script directory from the core.<br>
>><br>
>> It would be really great to have your views upon it.<br>
>><br>
>><br>
>> Hi,<br>
>><br>
>> Glad to see you here, it was great fun talking about that with you in<br>
>> Jaipur.<br>
>><br>
>> As Johnny found out we already started this discussion a while ago in<br>
>> <<a href="https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html" rel="noreferrer" target="_blank">https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html</a>><br>
>> <a href="https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html" rel="noreferrer" target="_blank">https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html</a>?<br>
>><br>
>> If we go further on that I would propose the following:<br>
>><br>
>> - Build an additional <activity>-info.rcc that contains the<br>
>> ActivityInfo.qml and the icon.<br>
>> - Remove the ActivityInfo.qml and the icon from full activity rcc<br>
>> - Make GCompris load the menu from the <activity>-info.rcc instead of the<br>
>> full rcc<br>
>> - Load the full rcc on entering the activity (or download it if we don't<br>
>> have it locally)<br>
>><br>
>> If we can do this we and this gives good results we can go further to<br>
>> include more requirements like:<br>
>><br>
>> - Inter Activity dependencies<br>
>> - Core API level (versioning of activities versus the core)<br>
>> - User interface option to download all the activities in one go<br>
>> - Adding new activities server side without reinstalling GCompris (means<br>
>> the flat list of activities in activities.rcc must be downloadable)<br>
>><br>
>> Devendra, if the GCompris team agree on this proposal, it would be nice<br>
>> to see you working on it.<br>
>><br>
>> Bruno.<br>
>><br>
>> _______________________________________________<br>
>> GCompris-devel mailing list<br>
>> <a href="mailto:GCompris-devel@kde.org">GCompris-devel@kde.org</a><br>
>> <a href="https://mail.kde.org/mailman/listinfo/gcompris-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/gcompris-devel</a><br>
>><br>
>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.kde.org/pipermail/gcompris-devel/attachments/20160319/aef53cb2/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.kde.org/pipermail/gcompris-devel/attachments/20160319/aef53cb2/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Sat, 19 Mar 2016 20:33:37 +0100<br>
From: JAZEIX Johnny <<a href="mailto:jazeix@gmail.com">jazeix@gmail.com</a>><br>
To: <a href="mailto:gcompris-devel@kde.org">gcompris-devel@kde.org</a><br>
Subject: Re: [GCompris-devel] Introduction + GCompris Idea Discussion<br>
Message-ID: <<a href="mailto:56EDA991.1070701@gmail.com">56EDA991.1070701@gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
Hi,<br>
<br>
On 03/19/16 14:49, Emmanuel Charruau wrote:<br>
> Hi,<br>
><br>
> If we go this way, and since we are reworking the architecture, could<br>
> we not implement a third level depth?<br>
> Let me give you an example.<br>
> We want to provide more specialised vocable classes for the lang<br>
> activity (the one to learn vocable).<br>
> We could have the following tree<br>
> vocable<br>
> - kids 5-6<br>
> - kids 7-9<br>
> - etc<br>
> but also<br>
><br>
> - nature<br>
> - geography<br>
><br>
> etc.<br>
><br>
> User would be able to first select the lang activity, then in lang<br>
> activity select for example "kids 5-9" and "nature" but not geography<br>
> as he does not want to download these classes.<br>
><br>
> What do you think?<br>
><br>
<br>
Basically it's adding downloadable datasets per activity?<br>
<br>
><br>
> Regards,<br>
><br>
> Emmanuel<br>
><br>
> ps: I would love to have this option for my grammatical activity, as<br>
> grammar contains a huge quantity of different competences.<br>
><br>
This way, you can also only download datasets for some language.<br>
><br>
><br>
> 2016-03-19 9:49 GMT+01:00 Bruno Coudoin <<a href="mailto:bruno.coudoin@gcompris.net">bruno.coudoin@gcompris.net</a><br>
> <mailto:<a href="mailto:bruno.coudoin@gcompris.net">bruno.coudoin@gcompris.net</a>>>:<br>
><br>
><br>
><br>
> Le 18/03/2016 22:31, Devendra Vyas a écrit :<br>
>> Hi!<br>
>> Congratulations for getting selected in GSoC'16<br>
>><br>
>> I am Devendra Vyas, fourth year undergrad studying Computer<br>
>> Science at The LNMIIT, Jaipur. I've a decent background in<br>
>> algorithms and data-structures, qualified for ACM-ICPC Regionals.<br>
>> I'm new to open source contribution and recently started<br>
>> contributing to GNU-Mailman(Postorius, as of now).<br>
>><br>
>> This year at conf.KDE I had a chat with Bruno Coudoin about<br>
>> reducing the size of the android app for the end user by<br>
>> providing two options -<br>
>> 1) Full download (Nothing new here, currently app works this way)<br>
>> 2) Providing an option to selectively download any activity<br>
>> I had a brief talk with Sagar and as far I have understood,<br>
>> basically the core directory is to be divided into categories as<br>
>> in, one part would contain basic scripts needed for any activity<br>
>> to render and other part would comprise of various scripts<br>
>> segregated in different directories may be for each activity.<br>
>> Now when a user downloads, we would just provide with the basic<br>
>> scripts needed for running any app. If the user opts for a full<br>
>> download then all the data(from both Activities and Core<br>
>> directory) will be pushed. Else, if he/she selects a particular<br>
>> activity we'll only push corresponding Activity directory and its<br>
>> corresponding script directory from the core.<br>
>><br>
>> It would be really great to have your views upon it.<br>
>><br>
>><br>
> Hi,<br>
><br>
> Glad to see you here, it was great fun talking about that with you<br>
> in Jaipur.<br>
><br>
> As Johnny found out we already started this discussion a while ago<br>
> in<br>
> <a href="https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html" rel="noreferrer" target="_blank">https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html</a>?<br>
><br>
> If we go further on that I would propose the following:<br>
><br>
> - Build an additional <activity>-info.rcc that contains the<br>
> ActivityInfo.qml and the icon.<br>
> - Remove the ActivityInfo.qml and the icon from full activity rcc<br>
> - Make GCompris load the menu from the <activity>-info.rcc instead<br>
> of the full rcc<br>
> - Load the full rcc on entering the activity (or download it if we<br>
> don't have it locally)<br>
><br>
<br>
We also have to take care about paying activities. If the user only<br>
wants one paying activity, will he pay for all?<br>
<br>
> If we can do this we and this gives good results we can go further<br>
> to include more requirements like:<br>
><br>
> - Inter Activity dependencies<br>
><br>
Won't it be needed? I mean, if user want to download an extended<br>
activity (erase_2clic, chronos...), he will need the activities they are<br>
based on (erase, babymatch...).<br>
<br>
> - Core API level (versioning of activities versus the core)<br>
><br>
<br>
It will be needed anyway because if we have some issues with one<br>
activity, it will be nice to know which version :).<br>
<br>
> - User interface option to download all the activities in one go<br>
> - Adding new activities server side without reinstalling GCompris<br>
> (means the flat list of activities in activities.rcc must be<br>
> downloadable)<br>
><br>
> Devendra, if the GCompris team agree on this proposal, it would be<br>
> nice to see you working on it.<br>
><br>
<br>
I have nothing against it if you are motivated to do it :).<br>
<br>
><br>
> Bruno.<br>
><br>
> _______________________________________________<br>
> GCompris-devel mailing list<br>
> <a href="mailto:GCompris-devel@kde.org">GCompris-devel@kde.org</a> <mailto:<a href="mailto:GCompris-devel@kde.org">GCompris-devel@kde.org</a>><br>
> <a href="https://mail.kde.org/mailman/listinfo/gcompris-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/gcompris-devel</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> GCompris-devel mailing list<br>
> <a href="mailto:GCompris-devel@kde.org">GCompris-devel@kde.org</a><br>
> <a href="https://mail.kde.org/mailman/listinfo/gcompris-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/gcompris-devel</a><br>
Johnny<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.kde.org/pipermail/gcompris-devel/attachments/20160319/9a2b7aab/attachment.html" rel="noreferrer" target="_blank">http://mail.kde.org/pipermail/gcompris-devel/attachments/20160319/9a2b7aab/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
GCompris-devel mailing list<br>
<a href="mailto:GCompris-devel@kde.org">GCompris-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/gcompris-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/gcompris-devel</a><br>
<br>
<br>
------------------------------<br>
<br>
End of GCompris-devel Digest, Vol 17, Issue 17<br>
**********************************************<br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="color:rgb(70,72,58);font-family:Georgia,Arial,Helvetica;font-size:small;line-height:35px">It is not your qualifications but your exposure in life that makes you who you are.</span></div><div dir="ltr"><span style="color:rgb(136,136,136)">Devendra Vyas</span><div style="color:rgb(136,136,136)">Final Year,Comp. Science</div><div style="color:rgb(136,136,136)">B.tech , The LNMIIT</div><div style="color:rgb(136,136,136)">Jaipur(Raj.)</div><div style="color:rgb(136,136,136)">Ph no. (+91)9460053732</div></div></div></div></div></div></div>
</div></div>