ubuntu-phone team mailing list archive

[Gerry Boland <gerry.boland@xxxxxxxxxxxxx>]

On 21/05/14 13:03, Thomas Voß wrote:
> On Tue, May 20, 2014 at 7:24 PM, Rick Spencer
> <rick.spencer@xxxxxxxxxxxxx> wrote:
>>
>>
>> On Tue, May 20, 2014 at 6:47 PM, Michał Sawicz <michal.sawicz@xxxxxxxxxxxxx>
>> wrote:
>>>
>>> On 20.05.2014 18:34, Kevin Gunn wrote:
>>>> But I guess your question is still valid, do we want to hold off landing
>>>> something that might make the sensitivity of rotation more annoying than
>>>> it is atm ?
>>>
>>> It won't make it more annoying, since apps rotate inside their own
>>> surfaces reacting to the same already. Only difference will be that the
>>> shell rotates as well.
>>>
> 
> Exactly, and I think the resulting experience would be quite messy to
> say the least :)
> 
>>>> I would (weakly) vote to land shell rotation independent of the
>>>> sensitivity bug...but we're weeks away from that, maybe it gets fixed
>>>> prior.
>>>
>>> +1, probably even higher priority would be to add the whole system of
>>> orientation locking and "negotiation" with apps.
> 
> +2.
> 
> I think there are 3 steps required to ensure that the shell and app
> rotation experience works well:
> 
> (1.) Adjust our current naive sensor implementation to leverage the
> fusioned rotation sensor available from Android. I listed the
> respective details on the bug report mentioned before. With that, we
> would be able to improve the app rotation experience first, and get
> some mileage on the newly introduced glue code.
>     -> Requires adjustments to: platform api, QtUbuntu sensors
> 
> (2.) Introduce a centralized decision maker that triggers UI rotation:
> Right now, the apps and the shell are independently listening to raw
> rotation sensor readings. For coordinated shell and app rotations,
> this central component (likely living in the shell) would act upon raw
> sensor readings and decide whether a rotation should be triggered. At
> that point, both the shell and the app(s) would receive the same
> trigger signal and start transitioning (plus some potential
> coordination on the transition).
>     -> Requires adjustments to: UI toolkit
>     -> Requires new rotation API -> U8

I agree with this, with small additions: Mir needs a small IPC addition
to allow shell to notify an application of the orientation change shell
decided. Also needed is IPC for application to inform shell the
orientations it supports (but can be done via Mir's existing side-channel)



> (3.) Teach the shell and Mir how to rotate.
> 
> All of the above three work items could be worked on in parallel.
> However, I would suggest to land them in the order presented before to
> prevent from UI issues with independently rotation apps and to address
> the potential problems mentioned in this thread.
> 
> Did I miss something?

I think we're covered!
-G



> 
> HTH,
> 
>   Thomas
> 
>> It sounds to me that we have one rotation system right now that is wrong in
>> a couple of ways. We have implemented and are about to embark on testing
>> another system for rotation that, while perhaps separate in some technical
>> ways, will none the less interaction with the first system at the user
>> experience level at a minimum.
>>
>> If it were me, I would very much want to pin down the app rotation system
>> before landing shell rotation so I had overall less complexity and fewer
>> changes to cope with.
>>
>> Cheers, Rick
>>
>>
>> --
>> Mailing list: https://launchpad.net/~ubuntu-phone
>> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ubuntu-phone
>> More help   : https://help.launchpad.net/ListHelp
>>
>