System compositors and surfaces created by nested servers

[Alan Griffiths]

On 15/06/15 15:38, Kevin Gunn wrote:
> Hey Alan - 
> For #1, I would think it's easy to conceive of use cases where you
> might have a system level arbiter that might want to have, for
> instance, multiple user sessions in a spread potentially.
> Maybe this means that the surfaces are still full screen, but just
> resized for such a view?
> in which case I'd still agree with you.

Yes, from the POV of the nested server its surfaces remain fullscreen
even when they are transformed by a spread by the host.

> Hard to say if as we split the greeter out, it might take on more
> shell like nature and have non-full screen elements to it. For now,
> though, I think it sounds like a reasonable limitation.
>
> And we are just talking about limits with respect to
> unity-system-compositor? emphasis on the "unity"....it's always been
> viewed as something specific to unity. Now, if we're talking about
> building in limitations to the host compositor of a nested config in
> general (applicable to any shell/ui)...I'd want to know more. Like how
> hard would we make it to then break this paradigm later?

Code that use Mir can always provide its own WindowManager, so what
we're providing is a bunch of helpful default behaviours that we think
appropriate to a system compositor. I've stolen what I think is generic
from USC and left the "chatting" it does with the display manager as a
configuration option (I've a WIP branch for USC that proves this).

HTH
Alan