[PATCH] Refine compositor grabs behavior

[Carlos Garnacho]

Hey there,

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.

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

- 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.

- 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.

- 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.

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.

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.

Cheers,
  Carlos

Carlos Garnacho (1):
  protocol: Define further the behavior of input on the presence of
    grabs

 protocol/wayland.xml | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)

-- 
2.5.0