[GCompris-devel] GCompris Architecture Reconfig Discussion

Johnny Jazeix jazeix at gmail.com
Wed Mar 23 11:22:21 UTC 2016 

2016-03-23 11:36 GMT+01:00 Devendra Vyas <devendra.y12 at lnmiit.ac.in>:

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

My point is more that installation and uninstallation should be together.
So if we decide that uninstall is more admin, I would think that it should
be the same for the installation. I don't see why we could install
activities as "simple user" and need to be in admin mode to uninstall them.


>
>>>
>>>> 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!
>
>
The student applications ends tomorrow so you should submit it before :).

Johnny


> 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/a1d576d4/attachment-0001.html>

More information about the GCompris-devel mailing list