If the client still has key focus, then it should get the key release. That sounds like a compositor bug to me.
On Thu, Jul 16, 2015 at 10:28 AM, Arnaud Vrac <raw...@gmail.com> wrote: > On Wed, Jun 10, 2015 at 5:20 PM, Jasper St. Pierre <jstpie...@mecheye.net> > wrote: > >> 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? > > > There's a case where that doesn't happen: if the key press triggers the > activation of an input method, which grabs the keyboard. The client still > keeps the focus and has no way to know if has to stop generating key repeats > for the key that triggered the activation. > > I'm getting exactly this issue, the keyboard grab is needed in the virtual > keyboard to be usable with the arrow keys. > >> >> >> >> 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 > > > -- > Arnaud -- Jasper _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel