<div dir="ltr"><div><div>Any client that gets a grab should *NOT* get any kind of focus-lost events during the grab. This is just going to confuse things and make it more difficult to implement toolkits. They know that events go to one place so they can easily handle internally the fact that some other widget lost the focus. This is the same as my oft-repeated request that clients getting enter events not get exit events (or at least swap the order so it gets the enter first), because the current scheme actually makes handling the events much more complicated, requiring lookahead to avoid drawing an incorrect display after getting the exit. </div>If another client (ie one without focus) manages to grab the pointer or keyboard it seems like sending the first client the same event it would get if the pointer or keyboard focus was moved away normally would work. Though I can imagine the client may want to know it is a grab, as it might want to avoid changing the highlighting since it expects to get the focus back "soon", but I'm not really sure if this decision would depend on the fact that it is a grab. The most useful cases are where the client that has focus also does the grab, though, this is certainly necessary to avoid the annoying titlebar flicker you get in some X window managers when popup menus are used. If any keys change during the grab (such as the Alt key mentioned) the client that got the focus-out event should get a focus-in event with the new keymap when the grab ends, so it knows this. </div></div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Jun 11, 2015 at 5:33 AM, Carlos Garnacho <<a href="mailto:carlosg@gnome.org" target="_blank">carlosg@gnome.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On mié, 2015-06-10 at 08:20 -0700, Jasper St. Pierre wrote: > On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho <<a href="mailto:carlosg@gnome.org">carlosg@gnome.org</a>> > 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. </div></div>The same happens on wayland *between clients*, and that's a good thing. Sure, it wasn't convenient on X11 for a WM, as yet another client. > 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". Precisely, a focus out/leave event with NotifyGrabbed means "I may never see this device again", The second enter/focus in event may not happen because the pointer/keyboard focus went elsewhere mid-grab, but for all that matters, the client already forgot about the device(s), so is in a consistent state. > > 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? Ok, we fixed keyboards. Keyboard is actually an easy usecase, they in the end have a binary state, even if for multiple keys, and not much retained state behind. Some observations though: - This works here because in this alt-tab example focus is being taken elsewhere, say we're raising a notification area or anything else that only steals focus temporarily, how do we convey the app "you should still consider yourself focused nonetheless, and still should appear as such"? - Do we take the same approach with wl_pointer, start telling "You must forget everything about this pointer on wl_pointer.leave events" and issue it mid-press if necessary? What about the legit places you may want enter/leave events while a button is pressed (eg. moving across subsurfaces) - Let's say this is enough for keyboards and pointers. What do we do about interfaces with no "leave" semantics like wl_touch? wl_touch.cancelled is not too thinly grained, mostly thought out for compositor gestures taking over the whole device/capability. Issuing wl_touch.up to "cancel" individual touches, or touches happening in an specific surface is definitely not what we want here. - Looking a bit forward to the future, we'll have tablets and buttonsets too, tablets will be specially funky as there's different interaction levels ("proximity" and pen in contact, pen buttons work on both states...), how do we behave orderly wrt the combination of those states? It strikes me as simpler having a new event that will also work for future capabilities than cramming current events with vague semantics that toolkits would need to heavily adapt for. > > What use > cases does this new event solve? I again recommend you to read <a href="http://lists.freedesktop.org/archives/way land-devel/2015-April/021407.html" rel="noreferrer" target="_blank">http://lists.freedesktop.org/archives/way land-devel/2015-April/021407.html</a> In short, I see all sorts of problems with simultaneous interaction (multitouch alone, and combinations of any two device capabilities), where one happens to trigger a xdg_popup, dnd or another compositor grab. The state in which the former/grabbing surface are left is both unspecified and broken in implementations. Cheers, Carlos <div class="HOEnZb"><div class="h5">_______________________________________________ wayland-devel mailing list <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </div></div></blockquote></div> </div>