[GCompris-devel] GCompris Architecture Reconfig Discussion

[Johnny Jazeix]

Hi,

2016-03-22 23:14 GMT+01:00 Bruno Coudoin <bruno.coudoin at gcompris.net>:

>
>
> 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> wrote:
>
>> Hi,
>>
>> 2016-03-22 13:10 GMT+01:00 Devendra Vyas < <devendra.y12 at lnmiit.ac.in>
>> 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.
>

I don't like the idea of telling the user he is offline. I, personally,
always use my tablet offline and would not like to be reminded that I'm not
connected. Maybe I'm a rare case :).
There is an option "automatic download", if it is checked, for me, there
should be no box.

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

Is it a good idea to separate the install/uninstall features? For me, it
comes together.

>
>
>> 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.
>
>
I don't know much the domain, but can using grayscale be a problem for some
people with visual deficiencies? In a way it's the same as using colored
icon but I'm not sure, so I prefer ask.


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

Sure, we have time to think of it and we should take this time to find the
best solution :).

Johnny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20160323/846c380a/attachment-0001.html>