What we do and don't expose to window management

[Alan Griffiths]

Inspired by a discussion with Chris I've been reading our code and
spotted some inconsistencies:

    1. In AbstractShell::modify_surface() we carefully consume the
    streams settings /and apply/ them before giving window management a
    chance to consider the modification request. Contrast this with
    AbstractShell::create_surface() which passes the stream settings to
    window management (which /could/ change them).

    Chris has logged lp:1619165 to say that window management shouldn't
    even see these settings. Hiding them in MirAL is probably enough
    until we incorporate it into Mir.

    But hiding the streams settings isn't the whole of the story: should
    we be applying it when window management rejects the request as ill
    formed?


    2. There's a similar story with confine_pointer - except that in
    this case in AbstractShell::modify_surface() we don't apply the
    setting if window management rejects the whole request by throwing
    an exception.

    It seems odd to be processing this property both in
    CanonicalWindowManagerPolicy::handle_modify_surface() and
    AbstractShell::modify_surface() I would expect it to be either
    handled by the policy or by the shell. Also note that there's no
    checking whether the application/surface is active - so any surface
    of any type (even a non-visible gloss of an application without
    current focus) can confine the cursor at any time.

What should the role of window management policy in handling the streams
and confine_pointer properties?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20160901/b7272701/attachment.html>