<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">Le 18/03/2016 22:31, Devendra Vyas a
écrit :<br>
</div>
<blockquote
cite="mid:CAKCFKBobcErgx17HLCsdbMz7QvMXY3=j=VagAZ6kdf6iiLkX2g@mail.gmail.com"
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>
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"><a class="moz-txt-link-freetext" href="https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html">https://mail.kde.org/pipermail/gcompris-devel/2015-September/004318.html</a></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.<br>
<br>
Bruno.<br>
</body>
</html>