[PATCH wayland] protocol: define further the behavior of input on the presence of grabs

[Carlos Garnacho]

On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote:
> What is the value of clients having this information? 

The same there is in having wl_touch.cancelled. See the cases in the
original email in the thread.

> I think we've
> tried to hide grab semantics from the point of view of the client and
> simply say "we can revoke input at any time, including in response to
> a request you make", which gives us, the compositor, a lot more 
> leeway
> with future possibilities.

Sure, I'm all for that. What I'd really want is having a way to tell
clients we do so. I'm totally fine with documenting the places where
this potentially happens on a per-case basis, even if the final wording
is "compositor dependent", same as for seat.release_input emission.

That said, toolkits/clients will surely expect some consistence across
compositors, so the leeway is relative.

> 
> Grabs were a major pain point in X11 since they were overspecified, 
> so
> we're trying to not fall into that same trap again.

I'm sure there is a lot of ground between "let's not overspecify" and
"let's go shopping".

It would be convenient first to identify what are the sore points with
X grabs. AFAICT, most of these come from grabs not being easily
transferred, and the WM/screensaver/etc not being more of a client to
revoke/break grabs. On wayland the compositor is completely free to do
as it pleases, with and without this change I'm proposing.

However, one thing that X did well is defining a consistent event
delivery model when grabs were being taken (well, except for touch
events...), so both the grabbing and the pre-grab windows are well
aware of what's going on, I think one is due in wayland, at least face
to clients.

> 
> For instance, if the user is in a game that has a keyboard grab and
> presses Alt-Tab to switch out, the client should just have its
> keyboard grab revoked without having to have that as a possibility in
> the protocol spec. Same thing with tray icon behavior, etc.

sure, in that case you'd still get wl_keyboard.leave and the client can
properly undo the key press / mods. But notice there is always a need
to know when to undo (eg. in your example above, the game might have
bound Alt to "release flares", if you first press Alt and then Tab, and
the client doesn't get the Alt key release, you don't want to leave
that stuck when you focus back)

> 
> Clients need to cope with losing mouse and keyboard focus at any 
> time,
> and with seats going away at any time. It's just how it is.

Toolkits are nothing else than giant state machines, they rely on a
meaningful event order, or some proper notification when things go
south. If you mess with that, you'll get clients in inconsistent
states, including:

- stuck buttons
- gestures listening to vanished touch sequences, unable to trigger
anymore
- stuck repeat keys

Cheers,
  Carlos