[GCompris-devel] Preparing release 0.50

[Holger Kaelberer]

On 17.10.2015 20:30, Bruno Coudoin wrote:

> Could we detect if sensors are available and use this in ActivityInfo to
> disable it?

Good idea. I added

bool ApplicationInfo::sensorIsSupported(const QString& sensorType)

to check for support for QtSensor classes and bound activation of balancebox to support for 
"QTiltSensor" on mobile platforms.

As the activity does not use any special features (especially QSensor::AxesOrientation) this should 
actually be enough to check for QtSensors support on a specific mobile platform.

With this also the core depends on the QtSensor module, of course.

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

Ok, will add a note before merging.

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

Just the idea to merge back(to) with home() and displayDialogs(array) with displayDialog(item).

I pushed a fix for the regression you found.

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

I see.

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

Will have a look ...

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

Yes, will merge it during the next few days, after some cleanup and another update of the builtin 
levels.

Thanks,
   Holger