System compositors and surfaces created by nested servers

[Alan Griffiths]

In extracting some sensible default behaviour from USC I've touched on
an issue (highlighted by Alexandros) that needs discussion. As some of
interested parties may not have tracked the MP I've copied it here:

> > We have always assumed one surface per system-compositor client, so it's not
> > clear what's the correct behavior if such a client creates and posts to
> > multiple surfaces. I guess the proposed approach of always focusing the
> > "default" surface is OK for now, but perhaps in the future
> on_session_ready
> > method should be extended to also provide the surface that became
> ready.
>
> What we actually have (c.f. the nested code and spinner) is one
> fullscreen surface for each output for each system-compositor client.
>

   
https://code.launchpad.net/~alan-griffiths/mir/msh_SystemCompositorWindowManager/+merge/261751/comments/655398
<https://code.launchpad.net/%7Ealan-griffiths/mir/msh_SystemCompositorWindowManager/+merge/261751/comments/655398>

There are actually two issues:

/1/ Will clients of system compositors server want anything other than
fullscreen surfaces? This is what the Mir code does by default, as does
Unity8 and the USC spinner. (When I checked with Gerry on IRC he didn't
foresee a need for anything else.)

/2/ How the focus should be managed for multiple surfaces. USC just uses
the "default" surface (i.e. the first) for the client and that is copied
by this MP. (This has to be wrong as only one screen is usable.)

My feeling that the answer to the first question is that our default
"window management" for a system compositor should only support
fullscreen surfaces but that we should follow up with logic for input
focus that recognises multiple screens/surfaces.

Any dissenting opinions?