mir::scene::Surface has no getter for orientation, just a setter

[Gerry Boland]

mir::scene::Surface has:
    virtual void set_orientation(MirOrientation orientation) = 0;

and mir::scene::SurfaceObserver has:
    virtual void orientation_set_to(MirOrientation orientation) = 0;

but there's no way to read the current orientation. Shell itself has to save that state externally, which is not ideal IMO

[Daniel van Vugt (vanvugt)]

I personally disapprove of this (and the existing setter too). Orientation should be an attribute of the screen. Not an attribute of any particular surface. Only if you want individual surfaces to rotate but not others (like Unity8 does now keeping the top bar unrotated) does it make sense. However I suspect that is a bug and not desired behaviour.

Also note set_orientation doesn't need to exist either. It is redundant with the older function set_transformation(). A getter already exists in the form of: Renderable::transformation()

I think we need to unify the redundant "orientation" and "transformation" functions. When that's done, we can make sure a getter is still available in the right place for you.

[Gerry Boland (gerboland)]

Note: orientation is simply a message to a surface to say "the current orientation is __" - it does not and should not impact the rendering.

We don't want clients listening for changes to the Screen orientation property, as with multiple clients running, but only 1 visible, they all re-orient their content for no reason which is costly. We prefer that shell can individually tell clients - here's the orientation you're currently showing at. It also helps for tablet, where side stage portrait is actually screen landscape.

[Alan Griffiths (alan-griffiths)]

I think the "set_..." name is raising a false expectation. As Gerry says it is a message from shell to client (that Mir coveys without interpretation).

If it were named "advise_orientation()" then there'd be no expectation of a corresponding "get..." member function.

The choice between:

1. the shell remembers the last orientation the orientation it has sent to a surface; or,
2. Mir remembers the last orientation sent by the shell so that the shell can query it.

[Daniel van Vugt (vanvugt)]

I think a better approach (which I've mentioned a few times in the past) is for clients to observe the aspect ratio they've been given by resize events and the current buffer:

   if (width > height)
       display myself in landscape mode
   else
       display myself in portrait mode

And then your compositor does the actual rotation as required. You don't need any "advise_orientation" for that. Just the existing surface/buffer dimensions.

That also works nicely for morphing rotation animations as the visible surfaces get resize events during such a rotation and halfway through one dimension will surpass the other, causing a smooth transition between portrait and landscape modes at just the right time.

[Daniel d'Andrada (dandrader)]

@vanvugt

That works when the compositor does all the rotation work, so all the client window does is respond to changes in its size to accommodate its contents accordingly. (Compositor-based rotation)

But currently it's the applications that rotate their own contents. So shell does have to tell the app in what orientation it should place its contents. (Client-based rotation)

Our target is to have compositor-based rotation for the vast majority of apps. But we should not do it for all of them. The camera application should do its own rotation because of the viewfinder. When you rotate the device the viewfinder stays put and only the buttons rotate. Doing compositor-based rotation for the camera app looks pretty bad compared to client-based.

Bottom line: we need both compositor-based and client-based rotation methods.

[Michał Sawicz (saviq)]

Syncing task from Mir.