[RFC 1/2] Introduce wl_probe_visible protocol

[Carlos Garnacho]

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.

Cheers,
  Carlos