<div dir="ltr">Hi,<div><br></div><div>If we go this way, and since we are reworking the architecture, could we not implement a third level depth?<br></div><div>Let me give you an example.</div><div>We want to provide more specialised vocable classes for the lang activity (the one to learn vocable).</div><div>We could have the following tree</div><div>vocable</div><div> - kids 5-6</div><div> - kids 7-9</div><div> - etc</div><div>but also</div><div><br></div><div> - nature</div><div> - geography</div><div><br></div><div>etc.</div><div><br></div><div>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.</div><div><br></div><div>What do you think?</div><div><br></div><div><br></div><div>Regards,</div><div><br></div><div>Emmanuel</div><div><br></div><div>ps: I would love to have this option for my grammatical activity, as grammar contains a huge quantity of different competences.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-19 9:49 GMT+01:00 Bruno Coudoin <span dir="ltr"><<a href="mailto:bruno.coudoin@gcompris.net" target="_blank">bruno.coudoin@gcompris.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<br>
<br>
<div>Le 18/03/2016 22:31, Devendra Vyas a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Hi!<br>
Congratulations for getting selected in GSoC'16<br>
<br>
</div>
<div class="gmail_default" style="font-family:trebuchet ms,sans-serif">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).<br>
<br>
</div>
<div class="gmail_default" style="font-family:trebuchet ms,sans-serif">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 - <br>
1) Full download (Nothing new here, currently app works this
way)<br>
</div>
<div class="gmail_default" style="font-family:trebuchet ms,sans-serif">2) Providing an option to selectively download
any activity<br>
</div>
<div class="gmail_default" style="font-family:trebuchet ms,sans-serif">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.<br>
</div>
<div class="gmail_default" style="font-family:trebuchet ms,sans-serif">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.<br>
<br>
</div>
<div class="gmail_default" style="font-family:trebuchet ms,sans-serif">It would be really great to have your views
upon it.<br>
<br>
</div>
<br>
</div>
</blockquote></span>
Hi,<br>
<br>
Glad to see you here, it was great fun talking about that with you
in Jaipur.<br>
<br>
As Johnny found out we already started this discussion a while ago
in <a href="https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html" target="_blank"></a><a href="https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html" 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
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 full rcc<br>
- Load the full rcc on entering the activity (or download it if we
don't have it locally)<br>
<br>
If we can do this we and this gives good results we can go further
to 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 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 see you working on it.<span class="HOEnZb"><font color="#888888"><br>
<br>
Bruno.<br>
</font></span></div>
<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></blockquote></div><br></div>