[GCompris-devel] GCompris Architecture Reconfig Discussion

Tue Mar 22 22:14:50 UTC 2016


Le 22/03/2016 15:27, Devendra Vyas a écrit :
> Hi
> Thanks for the prompt response!
>
> On Tue, Mar 22, 2016 at 6:27 PM, Johnny Jazeix <jazeix at gmail.com
> <mailto:jazeix at gmail.com>> wrote:
>
>     Hi,
>
>     2016-03-22 13:10 GMT+01:00 Devendra Vyas
>     <devendra.y12 at lnmiit.ac.in <mailto: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?
>
> 
> If it's available already then, we could incorporate it.
>  
>
>      
>
>         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).
>
> 
> First phase could be do it for android users only, as desktop users
> don't usually face space problems. However, once tested for android,
> we could discuss about it's implementation for desktop users as well.
> Does the approach feel right?
Well, the code is platform agnostic. It is just our decision to provide
a given version with a download mode for a given platform.
> We could provide the option of download, but if the user is offline,
> it would check and notify the user through a Dialog/Alert Box that the
> device is not connected to the internet. 
>  
Sure.
>  
>
>     Then, there should be the possibility to install/update/uninstall
>     any activity when you want using the configuration panel.
>
>  Sure, I've mentioned that in P-5 as an optional component, but now I
> think it could be added to the main To-Do list :)
I would like to avoid a such configuration panel. This feature belongs
to the admin mode. Let's not give the option to uninstall specific
activities.
>  
>
>     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?
>
> 
> One way that I could think of is, the icons of the activities that are
> downloaded will be in color and those not on device will be in
> grayscale. By doing this, we could use the existing menu. Also, if we
> do this, the already downloaded flag won't be needed. Now there could
> be multiple ways to display "can be upgraded" flag or info, one of
> them could be to have a separate configuration screen where every
> downloaded activity is listed and there the user could be notified of
> upgrades via some some button. The button would be active only when
> there is an upgrade possible.
Ok
>
>      
>
>         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.
>
> I'm a little unsure here. May be we could discuss this further as
> Sagar suggested.
>  
Yes, we can just decide not to manage versioning more than refusing to
install a new activity on a previous core. This is a safe bet and a good
start.

Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20160322/b93536aa/attachment.html>