<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 1, 2015 at 6:49 PM, Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
</div></div>I think that if we want to make it possible to change the relative<br>
position of a popup/tooltip/popover in response to the parent surface<br>
moving (like keeping a popover inside the visible area) we really should<br>
use the second approach. If we need to support letting the client draw<br>
its surface differently depending on where its placed, we should<br>
probably do something similar to a combination of<br>
xdg_surface.configure_ack and a synchronized subsurface. Sending updates<br>
for every movement will be very noicy, and it doesn't seem like<br>
something we want to expose.<br></blockquote><div><br></div><div>My main concern is that a client may want to create more than one popup window and position them relative to each other. This is the reason for the feedback of the position, it can move the other if the first one is placed in a different position than expected.<br><br></div><div>I don't see the noise being any worse than mouse moved events so I think it is ok that it may send a lot of these if the user moves the main window. Or the compositor could move all the child windows along with the main window, which means the relative location won't change (unless it hits the edge) and fewer events would be sent. This may actually be quite good for fancy menu systems.<br><br></div></div></div></div>