[RFC 1/2] Introduce wl_probe_visible protocol

[Jonas Ådahl]

On Thu, Oct 01, 2015 at 01:04:34PM +0200, Carlos Garnacho wrote:
> Hey Jonas!,
> 
> On Thu, Oct 1, 2015 at 8:51 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
> > wl_probe_visible (for now _wl_probe_visible) is a reintroduction of
> > the "wl_probe" method of making it possible to position a surface so
> > that it is completely visible, when positioning it relative to some
> > other already mapped surface. It works by checking what parts of a
> > rectangle relative to an existing surface would be visible, allowing
> > the client to reposition its surface accordingly.
> >
> > The protocol and implementation is based on patches by Rob Bradford
> > from 2013[0][1].
> >
> > [1] http://lists.freedesktop.org/archives/wayland-devel/2013-April/008665.html
> > [2] http://lists.freedesktop.org/archives/wayland-devel/2013-April/008666.html
> >
> > Signed-off-by: Jonas Ådahl <jadahl at gmail.com>
> > ---
> >
> > Hi,
> >
> > Some time ago I took the old "wl_probe" patches and updated them to
> > work today. The approach is mostly the same, but with some renaming and
> > moving around (it's for example not part of wl_shell anymore). It was
> > brought up on the mailing list recently, so I thought it could be a good
> > idea to make it easier to test on todays weston, so here it is.
> >
> > The are a few problems with this approach, such as:
> >
> > 1) It requires an extra roundtrip to create a popup/tooltip (not that
> > big of a deal though, I'd say).
> > 2) When the parent surface has non-trivial transformations (non-90
> > degree rotation etc), a resulting rectangle is ambigous. This could be
> > made implementation specific or with some required semantics (such as
> > prefer rectangles where more corners are untouched, prefer larger
> > rectangle etc).
> 
> I'm tempted to say this is compositor-specific territory, this depends
> a lot on how do compositors represent/map surfaces, and what do they
> allow to do with them at all. IMHO, mentioning that the coordinate
> axes of both surfaces are expected to be aligned is a generic enough
> common ground.
> 
> > 3) It may be abused to get an (incorrect) absolute surface position.
> > 4) It is racy - for a moving surface, the visibility will change as it
> > moves.
> 
> I would like to point out that it could be a common case. In GTK+ this
> would also be interesting for GtkPopover positioning, those are
> implemented as subsurfaces. It would be great to keep them onscreen
> (they are able to snap to either of four sides) but at the same time
> the toplevel window is draggable, so the positioning isn't static.
> Moreover, each next position tried must be probed too, because it
> might have the same space problem.
> 
> >
> > 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.
> 
> Perhaps changing this to a "subscription" model, where you pass
> surface+rectangle on the constructor and you receive events as parent
> surfaces move? I think it'd get rid of the roundtrip/raciness problem,
> seems a better fit for those "often repositioned" cases, and would be
> down to a single event for static cases (although you keep an object
> around). It would be great to attach this to the lifetime of the
> surface you're about to map though, or at least advise through docs.

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.


Jonas

> 
> Cheers,
>   Carlos