[GCompris-devel] GCompris Architecture Reconfig Discussion

[Johnny Jazeix]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20160322/19262c6c/attachment.html>