<div dir="ltr"><div><div><div><div>I don't see anything wrong with the compositor selecting the position for popups, and really don't see any way this "probe" idea can do better. This will avoid round trips, and also allow the compositor to move the popups if other obscuring objects appear after they are created. There are a few requirements however:<br><br></div><div>1. The client sends a desired position, and the result will be as close to this as the compositor can do.<br></div><div><br></div>2. The compositor must send an event telling the client when the popup moves and where to. This is not a global window position, it is relative to the parent surface.<br><br></div>3. The client must have a way to move the cursor so that it remains pointed at a desired widget. I think it would be acceptable to require the client to request a position such that if unchanged the cursor will be pointed correctly, and perhaps a flag indicating if the pointer warping is wanted. This sounds a lot like pointer-lock mode, too.<br><br></div><div>4. This needs to be applied to subsurfaces as well as popups. One of the many many reasons I think these two things need to be unified.<br></div><div><br></div>Some other random ideas:<br><br></div>1. Client may want to indicate an "important" rectangle/region, and that area outside of that can be clipped.<br><br><div><div>2. For rotations I think the compositor should be allowed to clip off some sharp corners, rather than strictly showing every pixel in the popup.<br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 1, 2015 at 4:04 AM, Carlos Garnacho <span dir="ltr"><<a href="mailto:carlosg@gnome.org" target="_blank">carlosg@gnome.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> A different approach of solving the same issue is to shift the<br>
> responsibility for positioning popups from the client to the<br>
> compositor. This requires a more complex protocol allowing the client<br>
> describing the expected semantics, as well as a roundtrip then the<br>
> client needs to know how the compositor positioned a given rectangle.<br>
> For the position readback case, this approach has the same racyness as<br>
> the approach in this patch, and adding a new kind of positioning logic<br>
> would need changing the protocol. This approach is what Mir is taking.<br>
><br>
> Personally, I'm not completely convinced a "wl_probe" way of improving<br>
> the menu positioning is the better option here, and would like to hear<br>
> what other think about this.</span></blockquote><div> </div></div></div></div>