ubuntu-phone team mailing list archive

[Ricardo Salveti de Araujo <ricardo.salveti@xxxxxxxxxxxxx>]

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,
-- 
Ricardo Salveti de Araujo