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