[GCompris-devel] Preparing release 0.50

[Bruno Coudoin]

Le 14/10/2015 01:12, Holger Kaelberer a écrit :
> Hi,
>
> my balancebox activity
> (https://github.com/hkaelber/GCompris-qt/tree/balancebox) is almost
> ready for a first release. I hope to finalize it this week, but am not
> in a hurry to get it into the upcoming release.
I have tested it and it is ok for me to integrate it.
>
> Johnny already reviewed and improved the cmake stuff, thanks for that!
>
> The activity is a bit special as it uses QSensors and the qml bindings
> of box2d. Therefore it might not work well on all platforms (I tested
> Linux and several Android flavours) It still needs to be tested on
> SailfishOS to find out if the QtSensor module works there as expected.
> I asked Alex to give it a try. If it does not I'd propose to simply
> disable it in ActivityInfo for any platform that does not work as
> expected.
Could we detect if sensors are available and use this in ActivityInfo to
disable it?
>
> I changed some things in core and for building. Before merging let me
> sum up some points here to give you a chance to improve it by your
> feedback:
>
> - qml-box2d as git submodule: balancebox uses the qml-box2d for
> movement and collision dynamics. The module is built automatically
> mainly for packaging it for Android. If there is a Linux distro that
> packages qml-box2d we should make our own box2d build configurable. I
> preferred a git submodule (over a cmake ExternalProject directly
> downloading from a git-URL) to avoid multiple downloads of the same
> repo for different target platforms.
It is fine to me but we have to document it on our wiki page.
>
> - ApplicationInfo::getSharedWritablePath() is used to provide a
> platform-specific writable path that can be accessed by other
> applications, too, to serve as storage for data exchange (like the 'My
> GCompris' folder in gtk+). For now this uses QStandardPaths and
> resolves to
>
>      On Android: /storage/emulated/0/GCompris (>= Android 4.2),
>                  /storage/sdcard0/GCompris (< Android 4.2)
>      On Linux: $HOME/.local/share/GCompris
>
Perfect.
> - Level editor: The activity allows for creating user levels (stored
> in above directory) via an editor. The editor is located in
> activities/balancebox/editor/.
>
> - DialogActivityFunc.dataValidationFunc exposes a hook for registering
> a simple  validation function for configuration data, thus allowing an
> activity to avoid saving invalid config data.
>
> - Multiple push/pop at once on the page view stack: To allow for
> pushing and popping >1 items on the page stack I added two more
> signals to ActivityBase
>
>     signal back(Item to)
>     signal displayDialogs(var dialogs)
>
> These are the bigger sisters of home() and displayDialog(). Was unsure
> whether they should better be merged together if possible and make
> them behave differently based on typeof argument.
These additions are welcome. Don't undestand what you mean in your
latest sentence. If we don't need them wet let's not code it.
>
> Besides these changes I noticed two points that we could improve:
>
> - Our activities are active once loaded after having started them,
> also after returning to the main menu. I noticed that because I saw
> balancebox still reacting to rotation changes being back in the main
> menu. For most of them this is probably not a problem as they don't do
> a lot without interaction. Nonetheless we might want to consider
> pausing them somehow after stop().
Yes, it has always been like that, when we leave an activity it stays
active in the background. It is the responsability of the activity to
stop its recurrent actions like timers in the stop(). I could not find a
way to make this automatic.
>
> - "Working" feedback: Activities that perform more intensive tasks (as
> balancebox does sometimes when initializing more complex level scenes)
> seem to freeze the application, especially on slow (android) devices,
> especially during activity startup. Might help to provide some visual
> feedback about that using something like a "Working"/"Loading" animation.
Maybe this can be done we the asynchronous feature of the Loader. If you
can find a generic way to do that we could put a loading animation in
the core.

So far, I suggest to integrate your work on the master branch and
complete the work from there. Is this fine for you?

Bruno.