[GCompris-devel] GCompris Architecture Reconfig Discussion

Wed Mar 23 10:36:14 UTC 2016

Hi

On Wed, Mar 23, 2016 at 3:01 PM, Johnny Jazeix <jazeix at gmail.com> wrote:

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

True, if the automatic download is checked then we may avoid the
alert/dialog box. However, if it is not checked and still user tries to
download an activity and he/she is not connected to internet, I think in
that case we should show alert/dialog 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.
>

As Bruno said, we would like to avoid as of now. However, if we find an
opportunity after implementing and testing the rest features and all agree
to it, then could we think of something like a long press that enables a
cross/delete button in the top right corner of every activity icon, that
would uninstall that activity?

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

One way of doing it could be that apart from grayscaling the icon we could
also shade it with diagonal lines (stripes). Or if not lines then may be
showing a download button on the icon itself or just below it. Also, we
could better visualize it via actually implementing it and based on
different opinions and results, finalize one. Suggestions welcomed :)

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

Also if you could suggest me one thing. Should I go for the proposal now,
so that I've sufficient time to accommodate your suggestions or should I
wait for the Phabricator discussion?
Any other suggestions also welcomed!

Thanks

>
>
> _______________________________________________
> GCompris-devel mailing list
> GCompris-devel at kde.org
> https://mail.kde.org/mailman/listinfo/gcompris-devel
>
>

-- 
It is not your qualifications but your exposure in life that makes you who
you are.
Devendra Vyas
Final Year,Comp. Science
B.tech , The LNMIIT
Jaipur(Raj.)
Ph no. (+91)9460053732
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20160323/8918c584/attachment-0001.html>