[RFC 1/2] Introduce wl_probe_visible protocol

[Bill Spitzak]

On Thu, Oct 1, 2015 at 6:49 PM, Jonas Ådahl <jadahl at gmail.com> wrote:

>
> I think that if we want to make it possible to change the relative
> position of a popup/tooltip/popover in response to the parent surface
> moving (like keeping a popover inside the visible area) we really should
> use the second approach. If we need to support letting the client draw
> its surface differently depending on where its placed, we should
> probably do something similar to a combination of
> xdg_surface.configure_ack and a synchronized subsurface. Sending updates
> for every movement will be very noicy, and it doesn't seem like
> something we want to expose.
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151002/c9cbcfb2/attachment.html>