On Mon, Jun 15, 2015 at 7:09 PM, Alan Griffiths
<alan.griffi...@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.)
There is conceivably a requirement for non-fullscreen clients to the
system compositor: authentication dialogs. It'd be nice to take the
polkit authentication dialog out of the user's session, for example,
and that would want to be overlaid on top of the user's session so not
necessarily fullscreen.
That said, this could be supported by requiring fullscreen and just
having most of the surface transparent.
/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?
I'm not sure that it makes sense to have surface-level focus for
system-compositor clients at all. It doesn't make sense for
user-sessions to have surface-level focus (indeed, I expect that once
we've got the input API for it they'll listen only to raw events).
It does make sense for an authentication dialog client to get
surface-level input events, but only because it should have at most one
surface.
Once we've got the missing input API bits hooked up I'd be in favour of
allowing exactly two classes of system-compositor client:
1) Shell-type clients, which get one fullscreen surface per output but
do not get surface-level input events, and
2) privileged-dialog-type clients, which get exactly one surface placed
wherever the system compositor thinks is best, and which gets normal
surface input.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
