[PATCH] Refine compositor grabs behavior

[Daniel Stone]

Hi Carlos,

On 12 November 2015 at 12:27, Carlos Garnacho <carlosg at gnome.org> wrote:
> I think it is worth to bring back some discussion on the client-side
> behavior during compositor grabs which I started a few months ago, for
> reference the thread started at:
> http://lists.freedesktop.org/archives/wayland-devel/2015-April/021407.html
>
> And the first patch sent was:
> http://lists.freedesktop.org/archives/wayland-devel/2015-June/022520.html
>
> This patch I'm sending is the result of discussion in that last thread,
> it further documents leave events so it is made clear how to deal with the
> cases when input is taken away from the surface, and adds a missing
> wl_touch.leave event, so there's means to "cancel" individual touch points.

Thanks for revising this!

> I'm however not too thrilled about reusing leave events for these
> situations, my reasons:

Hmm. I think it does make sense: leave means that the surface no
longer has the focus. In particular, it means that events on that
device (those devices) may happen without your knowledge. It's a good
signal that you can no longer expect the state to be coherent with the
event stream you're receiving.

> - Even if these were the intended semantics, everyone (including weston) is
>   getting this wrong, so this is effectively a behavior change that
>   compositors and toolkits do need to adapt to.

Hm, ouch. How is Weston getting this wrong at the moment? Is because
it forwards the release events?

> - The fact that this is just a footnote in docs will make it easy to miss,
>   so there will be a time when compositors jumping early on this will confuse
>   the hell out of clients that didn't adapt yet.

Sure, but to be fair, we really need to do a better job of - as Peter
suggested - the prose section of our documentation. Extensive notes in
each protocol is all good and well, but someone writing a compositor
will anyway desperately struggle with how to put everything together.

> - There are grabbing situations where the focus surfaces don't really change
>   within the compositor (eg. dragging a window, it will probably "have" the
>   keyboard focus, you however don't want keypresses to trigger anything on
>   the client). I admit this is an implementation detail, but temporarily
>   unsetting focus surfaces doesn't strike me as the best solution, plus there
>   are other cases where you legitimately want to move the focus to another
>   surface.

But how else do we tell clients that the device state is likely going
to be changing, in a way that it cannot inspect (until focus returns)?
Especially in a backwards-compatible manner ...

> My suggestion for this would be to split into a separate event per input
> interface, that'd make older clients as ignorant of these issues as they are
> now without actively breaking them. I'm however sending a patch as it was
> suggested in the previous threads.

I'm not really sure what you mean by this - can you please elaborate?

> Also, I would like to document a behavior meant for grabs, i.e. For most
> situations I think it makes sense for the compositor to grab not only the
> pointer/touchpoint triggering the grab, but all seat devices at once,
> because any of these could still be triggering stuff that renders this grab
> useless (eg. triggering an xdg_popup during window dragging). I can't think
> though of any place to put this piece of information, besides scattering it
> across the places where we expose "grabs" in wayland/xdg_shell/... protocols,
> suggestions here welcome.

What Peter said.

Cheers,
Daniel