What we do and don't expose to window management

[Andreas Pokorny]

Hi,


On Thu, Sep 1, 2016 at 1:02 PM, Alan Griffiths <alan.griffiths at canonical.com
> wrote:

> 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?
>
>
Since the streams used by a surface have no further semantics beyond a
function to get to a color for a pixel, changing which streams are part of
a surface is similar to changing the buffer content of a stream already
attached to a surface. So neither window management policy nor shell should
need to have access to streams changes. But that still does not answer the
question - if we consider blocking stream changes because window
mananagement requests were rejected we would also have to block any buffer
changes.

>
> 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.
>
>
My understanding was that AbstractShell only applies the confinement
setting of a surface if the respective surface is currently focused. Thus
hopefullly deactivates it when focus is changed. It sounds reasonable to
let the WindowManagement Policy decide whether a window may configure
confinement - but cannot think of any reasonable filtering policy, beyond
what is already done in unity8 to allow applications be full screen or not.

regards
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20160902/3679fe89/attachment.html>