ubuntu-phone team mailing list archive

[Dave Morley <davmor2@xxxxxxxxxxxxx>]

On 25/03/14 20:05, Ricardo Salveti de Araujo wrote:
> On Tue, Mar 25, 2014 at 4:54 PM, Thomas Voß <thomas.voss@xxxxxxxxxxxxx> wrote:
>> On Tue, Mar 25, 2014 at 8:25 PM, Ted Gould <ted@xxxxxxxxxx> wrote:
>>> On Tue, 2014-03-25 at 20:19 +0100, Thomas Voß wrote:
>>>
>>> Right now, we are considering the second alternative as it is much
>>> less intrusive. In the shell, we will leverage Mir's input event
>>> filter chains and offload reacting to certain kind of input events to
>>> a thread independent of Qt's UI thread. For the music player app, the
>>> issue will be solved when the media hub lands. The music player app
>>> will just "offload" music playback and playlist iteration to the media
>>> hub and we can expose the music player app to the usual application
>>> lifecycle (right now, it is granted an exception and is allowed to run
>>> when not focused).
>>>
>>> Please also note that the solution for the shell might serve as a
>>> reference for app authors who want to process events (such as sensor
>>> readings) at a higher rate than vblanc, and for that decouple their
>>> processing from the UI thread.
>>>
>>> The overall topic is quite complex and we might have missed something
>>> in evaluating the different alternatives, so consider this mail an
>>> early heads up together with a summary of our approach and ideas.
>>> Gerry is working on a POC for Unity8 right now, and we will keep you
>>> posted on the progress of that work.
>>>
>>> For the indicator-datetime case we were trying to send a notification to the
>>> shell and it appeared that the DBus event was held up by the UI thread.
>>> Could we also put QtDBus events into the non-UI thread?
>>
>> We certainly should investigate into that direction, but let's first
>> finish the POC and take it from there.
> 
> We just need to make sure we also have a solution for the regression we had
> with alarms, otherwise the image will still be blocked I guess.
> 
> Cheers,
> 

I would have the following tests in place for poc.

1. Alarms sound when the phone sleeps by itself and by pressing the
power button.

2. Music-app plays after the power button is hit or the phone sleeps.

3. The music-app can get to the next track for both phone sleeping and
power button press.

4. Volume can be altered on the music playing with the screen blanked.

5. A html playlist in grooveshark can play with the screen off.

That in theory would cover any instances I can think of off hand.  You
have a html5 app that is constrained a non-constrained music-app and the
alarms which uses an underlying api system and finally the hardware itself.

I wish you all the best with the poc I'm sure it will once more give us
a rocking system. :)


-- 
You make it, I'll break it!

I love my job :)
http://www.ubuntu.com
http://www.canonical.com

Attachment: signature.asc
Description: OpenPGP digital signature