Hi,
On Thu, Sep 1, 2016 at 1:02 PM, Alan Griffiths <alan.griffi...@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
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
