System compositors and surfaces created by nested servers

[Kevin Gunn]

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.
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?

br,kg

On Mon, Jun 15, 2015 at 4:09 AM, Alan Griffiths <
alan.griffiths at canonical.com> wrote:

> 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?
>
> --
> 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/88a3f08e/attachment.html>