[GCompris-devel] Plugin system for rcc

Thu Oct 1 16:39:40 UTC 2015

Hi,

Siddhesh informed us that the maximum size of android apk has been
increased to 100Mb
(http://thehackernews.com/2015/09/android-google-play-store.html) so
this let us some more time to think of the "best" solution.

As season of KDE will be starting soon, I was thinking it could be an
interesting project if a student want to do it (continue this
discussion to find a solution, maybe mockup, development will probably
have c++, qml, js, maybe cmake parts) along with the creation/port of
activities (if you have other ideas, fill free to share them)?

Johnny

2015-09-24 21:14 GMT+02:00 Holger Kaelberer <hk at elberer.de>:
> Hi,
>
> some thoughts:
>
> On 23.09.2015 01:56, Bruno Coudoin wrote:
>>
>>
>>
>> Le 22/09/2015 00:02, smirnoff.al at gmail.com a écrit :
>>>
>>> IMHO, the matter the fact, that GCompris loads languages and  other
>>> resources direct from internet is quite unusual for kde application.
>>
>>
>> Hi,
>>
>> Sure, we don't plan to change the way GCompris will be packaged on
>> GNU/Linux. We are looking at the specific issues that comes from the
>> mobile world and that we have to address.
>>
>> We won't find a universal solution to this anyway and we have to be
>> flexible enough to handle the different types of installations. We could
>> try to categorize the different use cases :
>>
>> - desktop: we already support this
>> - mobile (disk constrained): where to draw the line between shipped
>> content and online one and how to maintain the online side.
>
>
> - One possibility for 'the line drawn' was already mentioned: Ship
> everything that is included qua part of the demo version and make
> downloadable what is only part of the in-app purchased 'full' version.
>
> - I agree with Johnny, that we should ship some activities, so that the user
> can get some idea of what it is about. If I, as a user, would install
> something from the play store that provides only the bare executable without
> any activities, I would uninstall it again right away.
>
> - Maintain the online activities: As Johnny said already, we'd need more
> metadata (than the current Contents file), to allow the user to select
> between the available activities.
>
> For the status quo (i.e. regarding all activities we have currently in
> GCompris) we have several options, let me name two:
>
> 1. Keep minimal information about downloadable activities also packaged, to
> be able to present an overview of what there is available for download.
> 'Minimum' might then mean per activity ActivityInfo.qml + <activity>.svg.
> This would even allow to present the user a complete menu with the option to
> provide a 'u wanna download'-dialog when an activity is selected. (What we
> discussed at Randa, Bruno). Upstream/online we'd hold the complete rcc, that
> would be downloaded an registered on demand.
>
> 2. Have no information about downloadable-only activities packaged and
> provide them only online as a kind of a more complex 'Contents' directory,
> maybe providing the minimal information from 1. This would mean that a user
> *must* have online access even for seeing what there is available. This has
> the charm of being completely independent of the base application and could
> also be used as kind of a 'GCompris activity store' (you named it, Johnny
> ;-) which could be filled and extended independently of the base application
> shipped in the play store. This goes a bit beyond our current requirements,
> though.
>
> For both options we'd probably need to maintain some core API versioning
> PLUS make activities define min (and max?) required API versions. Even for a
> scenario like 1. you can easily imagine cases that would lead to runtime
> errors (like new activities are put online and an old version of the
> GCompris app tries to download them. Or: we change the core API in a
> non-backward compatible way -> old activities already downloaded don't run
> in new version of the base application.)
>
>> - offline (may be mobile, desktop or kiosk): need to provide a way to
>> provide a dataset even for mobile users having no net access.
>
>
> - Online full version: Kind of a full package for the target platforms in
> question. What about defining your 'full version' on the app store like
> that, Bruno? I know Android is somehow 'bound' to Google's play store, but
> let me just raise the question of whether there are no alternatives to this
> company's commercial distribution system with its strange constraints?
> Personally I've never used another android store, although I often install
> apk from other sources. For special use cases (like maybe school
> environments) it might be an option to simply install a full apk from
> gcompris.net or so and thus become more independent of foreign contraints.
>
> No idea, how things work (or don't work) for ios mobile devices.
>
> - Offline installation: Besides directly *installing* a full package, one
> could also directly copy actvities onto the devices. We already support such
> a manual install directory for the voices meant for copying directly an
> rcc-file via USB or so to be read by DownloadManager. Like that we could
> also support manual installations of activity rcc-files.
>
>>
>> We also have to consider the update scenarios, either full application
>> or only activities.
>
>
> Good point and kind of an extension of the current requirements for size
> limitations of mobile packages. As for above 2. some kind of API
> compatibility checks would be necessary for that. Maybe only by maintaining
> different activties/<api-version>/-directories upstream.
>
> Holger
>
>
>>
>> I don't have the solution, just trying to clarify our needs.
>>
>> Bruno.
>> _______________________________________________
>> GCompris-devel mailing list
>> GCompris-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/gcompris-devel
>>
> _______________________________________________
> GCompris-devel mailing list
> GCompris-devel at kde.org
> https://mail.kde.org/mailman/listinfo/gcompris-devel