ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

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?

Ted

Attachment: signature.asc
Description: This is a digitally signed message part