System compositors and surfaces created by nested servers

Kevin Gunn kevin.gunn at canonical.com
Mon Jun 15 15:17:12 UTC 2015


OK, makes sense, thanks for the color.
br,kg

On Mon, Jun 15, 2015 at 9:49 AM, Alan Griffiths <
alan.griffiths at 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 at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20150615/b23fffaf/attachment.html>


More information about the Mir-devel mailing list