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