On Wed, 19 Nov 2014 14:31:35 +0200 Giulio Camuffo <[email protected]> wrote:
> 2014-11-19 13:42 GMT+02:00 Pekka Paalanen <[email protected]>: > > On Tue, 18 Nov 2014 18:54:04 +0200 > > Giulio Camuffo <[email protected]> wrote: > > > >> 2014-11-13 13:30 GMT+02:00 Daniel Stone <[email protected]>: > >> > Hi, > >> > > >> > On Thursday, November 13, 2014, Giulio Camuffo <[email protected]> > >> > wrote: > >> >> > >> >> 2014-11-13 12:06 GMT+02:00 Daniel Stone <[email protected]>: > >> >> > But this is just a client issue, and nothing in sending the full keys > >> >> > array > >> >> > precludes this working. > >> >> > > >> >> > If Alt+X is a modifier (i.e. any time Alt+X is held, pressing Y > >> >> > triggers > >> >> > the > >> >> > shortcut), then the client can use the keys array to notice this, and > >> >> > ensure > >> >> > the shortcut is fired. > >> >> > > >> >> > If Alt+(X+Y) is a cumulative shortcut, then the client knows from > >> >> > seeing > >> >> > X > >> >> > in the enter array but not a key event, that it must wait for a > >> >> > release > >> >> > on X > >> >> > before it arms the shortcut for Y. > >> >> > >> >> But no, because, when the focus isn't switched, there is no enter > >> >> event and no keys array. The client has no idea X was pressed, so it > >> >> can't possibly trigger the binding. > >> >> So without the patch this is not consistent. Depending on whether the > >> >> compositor binding switches the focus, the client binding works or it > >> >> doesn't work. > >> > > >> > > >> > A problem we can solve by switching the focus. ;) I agree that it's > >> > annoying > >> > to always do this for every hotkey, so we could introduce a new > >> > wl_keyboard::leave_temporary which would inform the client that it's > >> > about > >> > to get another enter event very shortly, but shouldn't redraw itself > >> > insensitive or anything. > >> > > >> > Alternately, we could bump the wl_keyboard version to just allow for > >> > consecutive enter events and never send a leave in these temporal cases. > >> > >> Do we really need to bump the version? The description of > >> wl_keyboard.leave says " Notification that this seat's keyboard focus > >> is on a certain surface.", it doesn't say the leave and enter events > >> always go in pair, so it seems to me we can just send the new enters > >> without changing anything. > > > > We have lots of things we simply imply instead of having it written > > down. But I also think we don't even need to consider this. > > > > I don't see problem having the compositor itself steal the keyboard > > focus when a hotkey goes down. It would cause a wl_keyboard.leave to > > the client, and the keyboard focus would stay in the compositor as long > > as the grab is active (hotkeys always install a grab to prevent key > > events going to clients). When the grab ends, keyboard focus > > can return, and we naturally get the wl_keyboard.enter with the list of > > keys. I think this even allows both the compositor first handling the > > hotkey-down, and then the app seeing the key already-down. > > > > We even have one hotkey that won't release the grab on key-release: the > > debug key. Instead, it will wait for another key to be pressed, > > indefinitely IIRC. > > > > Just like Jasper said, it is a mistake to use wl_keyboard focus for > > window focus, xdg_shell has a separate mechanism for window focus. > > Window focus is a shell concept IMO, anyway. > > The only problem with that is that apps using wl_shell can only use > the keyboard focus as the window focus. Do we just say "too bad, > wl_shell is broken"? Yup. I think that's a reasonable thing to do. It's meant to be phased out even though we can "never" drop it completely. (except mutter already did, IIRC). It's not *that* bad. At worst, it's a flicker. At best, might not even be visible. And it doesn't work at all if you don't have a physical keyboard to begin with. > > > > I would favor the proper keyboard focus transitions I described above, > > rather than changing the protocol behaviour. It's easier and can be > > done in compositor only, without fixing all toolkits. > > > > That would be half of the fix, the other half being in Xwayland, right? > > Well, there is also the part about triggering the binding on key > release instead of press, only if no other key was pressed in the mean > time. I hope to send the patch(es) for that one of these days. That's a thing I didn't quite get yet... oh, wait, maybe I do now. Yeah. A bit of extra events to send, but shouldn't hurt at all. Mod down -> send key Mod down 's' down -> oooh, hotkey, steal kbd focus, send kbd.leave Then either 's' up -> do screenshot, restore kbd focus, send kbd.enter with Mod down. or 'x' down -> not our hotkey after all, restore kbd focus, send kbd.enter with Mod down, send key 'x' down Something like this, is it? Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
