<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Hi </div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Thanks for putting in your thoughts!</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 24, 2016 at 3:33 PM, Holger Kaelberer <span dir="ltr"><<a href="mailto:hk@elberer.de" target="_blank">hk@elberer.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'm currently on holidays with limited inet access :-( therefore replying late:<br>
<br>
On 23.03.2016 12:22, Johnny Jazeix wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
2016-03-23 11:36 GMT+01:00 Devendra Vyas <<a href="mailto:devendra.y12@lnmiit.ac.in" target="_blank">devendra.y12@lnmiit.ac.in</a> <mailto:<a href="mailto:devendra.y12@lnmiit.ac.in" target="_blank">devendra.y12@lnmiit.ac.in</a>>>:<br>
<br>
Hi<span class=""><br>
<br>
On Wed, Mar 23, 2016 at 3:01 PM, Johnny Jazeix <<a href="mailto:jazeix@gmail.com" target="_blank">jazeix@gmail.com</a> <mailto:<a href="mailto:jazeix@gmail.com" target="_blank">jazeix@gmail.com</a>>> wrote:<br>
<br>
Hi,<br>
<br>
2016-03-22 23:14 GMT+01:00 Bruno Coudoin <<a href="mailto:bruno.coudoin@gcompris.net" target="_blank">bruno.coudoin@gcompris.net</a><br></span>
<mailto:<a href="mailto:bruno.coudoin@gcompris.net" target="_blank">bruno.coudoin@gcompris.net</a>>>:<span class=""><br>
<br>
<br>
<br>
Le 22/03/2016 15:27, Devendra Vyas a écrit :<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Hi<br>
Thanks for the prompt response!<br>
<br>
On Tue, Mar 22, 2016 at 6:27 PM, Johnny Jazeix <<a href="mailto:jazeix@gmail.com" target="_blank">jazeix@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:jazeix@gmail.com" target="_blank">jazeix@gmail.com</a>>> wrote:<br>
<br>
Hi,<br>
<br>
2016-03-22 13:10 GMT+01:00 Devendra Vyas<br></span>
<<mailto:<a href="mailto:devendra.y12@lnmiit.ac.in" target="_blank">devendra.y12@lnmiit.ac.in</a>><a href="mailto:devendra.y12@lnmiit.ac.in" target="_blank">devendra.y12@lnmiit.ac.in</a><br>
<mailto:<a href="mailto:devendra.y12@lnmiit.ac.in" target="_blank">devendra.y12@lnmiit.ac.in</a>>>:<span class=""><br>
<br>
Hi<br>
<br>
This mail comprises of what I've understood after the discussions on mailing<br>
lists and IRC regarding modifying the core of Gcompris.<br>
<br>
Purpose: To provide users an option to download activities as per their<br>
wish/need. Keeping the full download option intact.<br>
<br>
Phases of development:<br>
P-1 -> Separate ActivityInfo.qml and icons from some activities and make new<br>
ActivityInfo.rcc. See whether we are successfully able to load them. The<br>
activities selected here will not have have any inter-dependencies on some<br>
other activity.<br>
<br>
P-2 -> Now for the activities that are inter-dependent, I think we'll have to<br>
code a new download manger in a way that it downloads all dependencies<br>
required for running that activity and nothing extra. As mentioned earlier by<br>
Johnny, erase_2clic needs erase. So download manager's code will manage<br>
accordingly.<br>
<br>
<br>
I'm not sure we need to update the DownloadManager in this case, we can just first<br>
download the dependencies and then the wanted package. I think there is a system<br>
with a job list that should work here?<br>
<br>
<br>
If it's available already then, we could incorporate it.<br>
</span></blockquote></blockquote>
<br>
DM does not yet know anything about dependencies between downloadable resources. Can be added. Either there or in a separate module, like "ActivityManager" or so.<br>
<br>
One could also think about factoring code that is common to multiple activities out to some kind of "activity supporting lib" that is semantically located somewhere between core and activitites. That would allow to really only install the one activity a user wants to install instead of pulling in others it depends upon. Not sure if this would be worth it. Thinking about the lang/words function that is used in quite some activities already this would probably be worth it. Whereas for others like "click_on_letter"/"click_on_letter_up" this might seem too much overhead.</blockquote><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline"></div></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline">I think if once we are able to do it without the factoring, I would really like to go for the factoring. I even thought of it while discussing it with Sagar earlier. </div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
P-3 -> Now providing option of selective activity download to end-user in a<br>
way that it is easy to understand. I suggest that we have two buttons at the<br>
very beginning of the app, that prompts user with two options/buttons: a) Full<br>
Download b) Selective download<br>
<br>
<br>
There are two things to consider: the first run where your solution works (should<br>
it depend on the platform? I mean for Desktop packages, do we propose all the<br>
activities directly? We also need to take care of not propose it if the user is<br>
not connected to internet, it should work offline).<br>
<br>
<br>
First phase could be do it for android users only, as desktop users don't usually face<br>
space problems. However, once tested for android, we could discuss about it's<br>
implementation for desktop users as well. Does the approach feel right?<br>
</blockquote>
Well, the code is platform agnostic. It is just our decision to provide a given version<br>
with a download mode for a given platform.<br>
</blockquote>
<br></span>
ACK, once the feature is in place it is supposed to work on any platform.<br>
<br>
For desktop platforms I guess the 'normal' use-case would be that GCompris is installed with activitites as packaged for the distro. Irrespective of that the download code can check for updates of activities upstream and install them if requested by the user.<br>
<br>
As for voices we'd probably need several activity-rcc-directories to check for available activities to load as the download target directory will be different from the system-dir where packaged activity rcc files will be placed during install. The activity loader should then be smart enough to always load the newest available activity compatible with the current core version, for cases where we have different versions of an activity available.<div><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We could provide the option of download, but if the user is offline, it would check<br>
and notify the user through a Dialog/Alert Box that the device is not connected to the<br>
internet. <br>
</blockquote>
Sure.<br>
<br>
<br>
I don't like the idea of telling the user he is offline. I, personally, always use my tablet<br>
offline and would not like to be reminded that I'm not connected. Maybe I'm a rare case :).<br>
There is an option "automatic download", if it is checked, for me, there should be no box.<br>
<br>
<br>
True, if the automatic download is checked then we may avoid the alert/dialog box. However, if<br>
it is not checked and still user tries to download an activity and he/she is not connected to<br>
internet, I think in that case we should show alert/dialog box<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Then, there should be the possibility to install/update/uninstall any activity<br>
when you want using the configuration panel.<br>
<br>
Sure, I've mentioned that in P-5 as an optional component, but now I think it could<br>
be added to the main To-Do list :)<br>
</blockquote>
I would like to avoid a such configuration panel. This feature belongs to the admin<br>
mode. Let's not give the option to uninstall specific activities.<br>
<br>
<br>
Is it a good idea to separate the install/uninstall features? For me, it comes together.<br>
<br>
<br>
As Bruno said, we would like to avoid as of now. However, if we find an opportunity after<br>
implementing and testing the rest features and all agree to it, then could we think of something<br>
like a long press that enables a cross/delete button in the top right corner of every activity<br>
icon, that would uninstall that activity?<br>
<br>
<br>
My point is more that installation and uninstallation should be together. So if we decide that<br>
uninstall is more admin, I would think that it should be the same for the installation. I don't see<br>
why we could install activities as "simple user" and need to be in admin mode to uninstall them.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For the selective download, do you have an idea of what it should look like, which<br>
information should be displayed? The icon, name, difficulty, tags, version? Can we<br>
reuse the existing menu to display these activities (and instead of flagging<br>
favorite, we can flag "already downloaded/can be upgraded") or maybe use a list?<br>
<br>
<br>
One way that I could think of is, the icons of the activities that are downloaded will<br>
be in color and those not on device will be in grayscale.<br>
</blockquote>
<br>
<br>
I don't know much the domain, but can using grayscale be a problem for some people with<br>
visual deficiencies? In a way it's the same as using colored icon but I'm not sure, so I<br>
prefer ask.<br>
<br>
<br>
One way of doing it could be that apart from grayscaling the icon we could also shade it with<br>
diagonal lines (stripes). Or if not lines then may be showing a download button on the icon<br>
itself or just below it. Also, we could better visualize it via actually implementing it and<br>
based on different opinions and results, finalize one. Suggestions welcomed :)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
By doing this, we could use the existing menu. Also, if we do this, the already<br>
downloaded flag won't be needed. Now there could be multiple ways to display "can be<br>
upgraded" flag or info, one of them could be to have a separate configuration screen<br>
where every downloaded activity is listed and there the user could be notified of<br>
upgrades via some some button. The button would be active only when there is an<br>
upgrade possible.<br>
</blockquote>
Ok<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
P-4 -> Versioning of APIs. I'm a little unsure here. We have two issues to<br>
handle here: a) Avoid download of duplicate activity on the user end b) check<br>
and update correct version of activity to core. I think one of the ways could<br>
be, while we are creating a separate activityInfo.rcc for every activity, the<br>
download manger could check the corresponding ActivityInfo.qml file in<br>
activityInfo.rcc for version and then perform the necessary action.<br>
<br>
<br>
To avoid duplicate, you should already know if you have the activity or not, and<br>
its version. I think we can only have one downloadable_activities.rcc on server<br>
containing:<br>
|- activity1/{icon/ActivityInfo.qml}<br>
|- activity2/{icon/ActivityInfo.qml}<br>
|- activity3/{icon/ActivityInfo.qml} ...<br>
<br>
This file would be downloaded, if automatic download is activated, when the user<br>
starts the application if the version is more recent else with a button in the<br>
config, like for the voices. Then, we can see for each activity if we have a more<br>
recent one or not.<br>
<br>
For knowing the minimum/maximum core version, we can probably add it in the<br>
ActivityInfo.qml. We have a createdInVersion field, maybe we can improve it.<br>
<br>
I'm a little unsure here. May be we could discuss this further as Sagar suggested.<br>
</blockquote>
Yes, we can just decide not to manage versioning more than refusing to install a new<br>
activity on a previous core. This is a safe bet and a good start.<br>
<br>
Bruno.<br>
<br>
<br>
Sure, we have time to think of it and we should take this time to find the best solution :).<br>
</blockquote>
<br></div></div>
Regarding versioning:<br>
<br>
Good idea to maintain everything needed for activity compatibility within ActivityInfo.qml<br>
<br>
For checking whether an activity is compatible with a core/app we need a new coreApiVersion defined in the core/app, right? That version would be different from the applications version and would be increased whenver we add a new core function (used by an activity) or drop an older one (if we ever do that). Or is there an easier way to track API compatibility?<br>
<br>
On the activity side we might need at least something like minCoreVersion.<br>
<br>
Also maxCoreVersion might be needed unless we can ensure to always change the core in a backward compatible way. Otherwise we might end up in runtime errors in case an 'old' activity is loaded by a 'new' core that does no longer provide the API interface the 'old' activity needs. Consider the case that the user updated the gcompris app(lication) and the new core does no longer support the downloaded activities. The option to keep backward compatibility is quite a restriction but also more convenient to code.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline">I might be wrong, but I would like to think of maxCoreVersion</div> <div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline">as a sort of safety net for future development prospects. As in if there arise a case where in an activity cannot be rendered by the newest core version due to some major changes, thus lose of backward compatibility, then we might be able to inform the user in a lucid fashion.</div></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline">I also would like to know am I supposed to incorporate these points in the proposal or should I leave them as of now to further discussions?</div></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline">Holger, I know you are running low on internet connectivity. Still if you could find some time to review the proposal, it would be really great. </div></div><div><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;display:inline"><br></div></div><div><span style="font-family:'trebuchet ms',sans-serif"><br></span></div><div><span style="font-family:'trebuchet ms',sans-serif">Devendra</span><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Holger<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
Johnny<br>
<br>
<br>
Also if you could suggest me one thing. Should I go for the proposal now, so that I've<br>
sufficient time to accommodate your suggestions or should I wait for the Phabricator discussion?<br>
Any other suggestions also welcomed!<br>
<br>
<br>
The student applications ends tomorrow so you should submit it before :).<br>
<br>
Johnny<br>
<br>
Thanks<br>
<br>
<br>
<br>
_______________________________________________<br>
GCompris-devel mailing list<br></span>
<a href="mailto:GCompris-devel@kde.org" target="_blank">GCompris-devel@kde.org</a> <mailto:<a href="mailto:GCompris-devel@kde.org" target="_blank">GCompris-devel@kde.org</a>><span class=""><br>
<a href="https://mail.kde.org/mailman/listinfo/gcompris-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/gcompris-devel</a><br>
<br>
<br>
<br>
<br>
--<br>
It is not your qualifications but your exposure in life that makes you who you are.<br>
Devendra Vyas<br>
Final Year,Comp. Science<br>
B.tech , The LNMIIT<br>
Jaipur(Raj.)<br>
Ph no. (+91)9460053732<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
GCompris-devel mailing list<br>
<a href="mailto:GCompris-devel@kde.org" target="_blank">GCompris-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/gcompris-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/gcompris-devel</a><br>
<br>
</span></blockquote>
</blockquote></div><br><div><br></div>
</div></div>