OK, makes sense, thanks for the color. br,kg On Mon, Jun 15, 2015 at 9:49 AM, Alan Griffiths < alan.griffi...@canonical.com> wrote:
> 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 >
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
