<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>