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 -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
