On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho <carl...@gnome.org> wrote: > 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.
Yeah, transferring grabs race-free, a lack of being able to override or revoke grabs are the top two. But focus management + grabs in X11 is tricksy and sort of awkward: if I take a keyboard grab, key focus can still navigate around as usual, we'll just get NotifyWhileGrabbed as our detail. > 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. Did it? I don't know of any model that lets me know when a client has taken a grab or ungrabs their existing grab. The exception is that I believe if I'm the key or pointer focus, I'll get a FocusOut / Leave event with the "NotifyGrabbed" detail, and when the grab is dropped (and I am still the key focus / pointer focus, which is not guaranteed!), we'll get the reverse event with "NotifyUngrabbed". And in X11, this is actually good, because such an event would be racy: some other client might have taken a grab in such a time. And it happens all the time because of passive grabs, including X11's own implicit passive grab on the pointer. Anyway, this model matches well with wl_keyboard.leave / wl_pointer.leave being sent at the start of device grabs. >> >> 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) The client gets a wl_keyboard.leave. Is that not good enough? What use cases does this new event solve? >> 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 -- Jasper _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel