[GCompris-devel] GCompris Architecture Reconfig Discussion

[Sagar Chand Agarwal]

Hello all,

This looks good. We should have one full discussion on it. My apologies for
not mailing earlier.

Cheers ,
Sagar

On Tue, 22 Mar 2016 6:27 pm Johnny Jazeix, <jazeix at gmail.com> wrote:

> Hi,
>
> 2016-03-22 13:10 GMT+01:00 Devendra Vyas <devendra.y12 at lnmiit.ac.in>:
>
>> Hi
>>
>> This mail comprises of what I've understood after the discussions on
>> mailing lists and IRC regarding modifying the core of Gcompris.
>>
>> Purpose: To provide users an option to download activities as per their
>> wish/need. Keeping the full download option intact.
>>
>> Phases of development:
>> P-1 -> Separate ActivityInfo.qml and icons from some activities and make
>> new ActivityInfo.rcc. See whether we are successfully able to load them.
>> The activities selected here will not have have any inter-dependencies on
>> some other activity.
>>
>> P-2 -> Now for the activities that are inter-dependent, I think we'll
>> have to code a new download manger in a way that it downloads all
>> dependencies required for running that activity and nothing extra. As
>> mentioned earlier by Johnny, erase_2clic needs erase. So download manager's
>> code will manage accordingly.
>>
>>
> I'm not sure we need to update the DownloadManager in this case, we can
> just first download the dependencies and then the wanted package. I think
> there is a system with a job list that should work here?
>
>
>> P-3 -> Now providing option of selective activity download to end-user in
>> a way that it is easy to understand. I suggest that we have two buttons at
>> the very beginning of the app, that prompts user with two options/buttons:
>> a) Full Download b) Selective download
>>
>>
> There are two things to consider: the first run where your solution works
> (should it depend on the platform? I mean for Desktop packages, do we
> propose all the activities directly? We also need to take care of not
> propose it if the user is not connected to internet, it should work
> offline).
> Then, there should be the possibility to install/update/uninstall any
> activity when you want using the configuration panel.
>
> For the selective download, do you have an idea of what it should look
> like, which information should be displayed? The icon, name, difficulty,
> tags, version? Can we reuse the existing menu to display these activities
> (and instead of flagging favorite, we can flag "already downloaded/can be
> upgraded") or maybe use a list?
>
>
>> P-4 -> Versioning of APIs. I'm a little unsure here. We have two issues
>> to handle here: a) Avoid download of duplicate activity on the user end b)
>> check and update correct version of activity to core. I think one of the
>> ways could be, while we are creating a separate activityInfo.rcc for every
>> activity, the download manger could check the corresponding
>> ActivityInfo.qml file in activityInfo.rcc for version and then perform the
>> necessary action.
>>
>
> To avoid duplicate, you should already know if you have the activity or
> not, and its version. I think we can only have one
> downloadable_activities.rcc on server containing:
> |- activity1/{icon/ActivityInfo.qml}
> |- activity2/{icon/ActivityInfo.qml}
> |- activity3/{icon/ActivityInfo.qml} ...
>
> This file would be downloaded, if automatic download is activated, when
> the user starts the application if the version is more recent else with a
> button in the config, like for the voices. Then, we can see for each
> activity if we have a more recent one or not.
>
> For knowing the minimum/maximum core version, we can probably add it in
> the ActivityInfo.qml. We have a createdInVersion field, maybe we can
> improve it.
>
>
> P-5 -> If all of the above is done, I think we could also think of
>> implementing an option that allows user to delete a particular activity.
>> Suppose someone has completed all the levels of the activity and doesn't
>> use the activity anymore then this option would help there.
>> Implementation of P-5 -> We can add a ActivityHandler.cpp in the core
>> that will keep track of this.
>> In my humble opinion, this would take around 12 weeks including the
>> testing.
>>
>> If mentors think this is small enough for GSoC, I'm ready to discuss and
>> implement an additional option suggested by Emmanuel for allowing the user
>> to download part of activity as per the age of the kid (If not for all then
>> for some of the activities).
>>
>>
> Time wise, I think it should fit in a gsoc.  The idea is almost clear,
> there will still be time when we'll need to discuss so it's 12 weeks less
> the discussions ;).
>
> Johnny
>
>
>> I would request the review of the mentors on this that whether this could
>> be a probable proposal for GSoC'16.
>>
>> Thanks
>> ​Devendra​
>> It is not your qualifications but your exposure in life that makes you
>> who you are.
>>
>>
>>
>> _______________________________________________
>> GCompris-devel mailing list
>> 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
>
-- 
Sagar Chand Agarwal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20160322/27b2f57f/attachment-0001.html>