<div dir="ltr"><div><div><div><div><div>Alan is right with the modify surface *could* possibly confine a surface thats unfocused though this would quickly resolve it self if someone where to switch windows. The issue is we dont check if the surface we are modifying in AbstractShell:modify_surface() is focused. Ill get a fix up for that.<br><br></div>The reason we have two cases of handling: WM + AbstractShell.<br><br>the handle_modify_surface:<br></div>  Is in charge of setting surface to be in a confined state or not ie. if its allowed for this surface to be confined.<br><br></div>the modify_surface:<br></div><div>  Checks with WM first about the settings<br></div>  If it allows for confine state for the surface and (bug to be fixed) is focused we need to set seat to confine this region.<br><br></div>Now we *would* be able to avoid this if the WM/Surface could change the Seat but it sounds better to keep it in the abstract shell. The only other way is to change the surface observer to say we allow confinement for x,y,w,h now. (which we did and reverted since the observer should state that something has changed not that it *should* change something now)<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 2, 2016 at 6:23 AM, Andreas Pokorny <span dir="ltr"><<a href="mailto:andreas.pokorny@canonical.com" target="_blank">andreas.pokorny@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Sep 1, 2016 at 1:02 PM, Alan Griffiths <span dir="ltr"><<a href="mailto:alan.griffiths@canonical.com" target="_blank">alan.griffiths@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <p>Inspired by a discussion with Chris I've been reading our code
      and spotted some inconsistencies:</p>
    <blockquote>
      <p>1. In
        
        AbstractShell::modify_surface(<wbr>) we carefully consume the <tt>streams</tt>
        settings <i>and apply</i> them before giving window management
        a chance to consider the modification request. Contrast this
        with AbstractShell::create_surface(<wbr>) which passes the stream
        settings to window management (which <i>could</i> change them).</p>
      <p>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.<br>
      </p>
      <p>But hiding the <tt>streams</tt> settings isn't the whole of
        the story: should we be applying it when window management
        rejects the request as ill formed?<br></p></blockquote></div></blockquote><div><br></div></span><div>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.  <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><blockquote><p>
      </p>
      <p><br>
      </p>
      <p>2. There's a similar story with <tt>confine_pointer</tt> -
        except that in this case in AbstractShell::modify_surface(<wbr>) we
        don't apply the setting if window management rejects the whole
        request by throwing an exception.</p>
      <p>It seems odd to be processing this property both in
        CanonicalWindowManagerPolicy::<wbr>handle_modify_surface() and
        AbstractShell::modify_surface(<wbr>) 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.</p></blockquote></div></blockquote><div><br></div></span><div>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. <br><br></div><div>regards<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Andreas<br></div></font></span></div></div></div>
<br>--<br>
Mir-devel mailing list<br>
<a href="mailto:Mir-devel@lists.ubuntu.com">Mir-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/mir-devel</a><br>
<br></blockquote></div><br></div>