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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel