[RFC 1/2] Introduce wl_probe_visible protocol

[Bill Spitzak]

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:

1. The client sends a desired position, and the result will be as close to
this as the compositor can do.

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.

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.

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.

Some other random ideas:

1. Client may want to indicate an "important" rectangle/region, and that
area outside of that can be clipped.

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.


On Thu, Oct 1, 2015 at 4:04 AM, Carlos Garnacho <carlosg at gnome.org> wrote:

>
> > A different approach of solving the same issue is to shift the
> > responsibility for positioning popups from the client to the
> > compositor. This requires a more complex protocol allowing the client
> > describing the expected semantics, as well as a roundtrip then the
> > client needs to know how the compositor positioned a given rectangle.
> > For the position readback case, this approach has the same racyness as
> > the approach in this patch, and adding a new kind of positioning logic
> > would need changing the protocol. This approach is what Mir is taking.
> >
> > Personally, I'm not completely convinced a "wl_probe" way of improving
> > the menu positioning is the better option here, and would like to hear
> > what other think about this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151001/253e1ebf/attachment.html>