[PATCH 0/2] RFC: Introduce keyboard grabbing and shortcuts inhibitor protocols
ofourdan at redhat.com
Thu Mar 23 07:35:03 UTC 2017
> I can't imagine blocking all/none shortcuts can be the only choices.
> What if the nested wm does not use one of the shortcuts? And whether a
> particular shortcut is used can vary: a tab between windows may not
> work if you are on the last window, in that case it would be nice if
> tab then went out of the nested wm and to the next main window.
> An "I consumed/ignored this event" request sent back from clients to
> the compositor would allow this to work. This also matches how a
> number of toolkits work so it would make integration of them into
> desktops better.
I'd rather keep the protocol lean and simple.
If anything, existing application do not need to know which shortcuts are used, for example, virt-viewer has no idea what particular shortcuts the desktop running on the guest OS is using.
And toolkits do not know that either.
> As for the X thing, I don't see why any new api is necessary. The X
> emulator can just set normal Wayland keyboard focus to the window and
> do whatever is necessary so that moving the focus away is discouraged
> and it is easy to get the focus back (ie mouse enter and click try to
> put it back), rather than add an extremely dangerous and unwanted api
> from X to Wayland.
It is necessary for  and , ie X11 applications that map an override redirect window and grab the keyboard. I tried the appoach you mention and was denied, on valid the grounds  that O-R should not be focused by the WM.
While this works just fine in X11 thanks to the keyboard grab, it cannot work in Xwayland without a mechanism that route the keyboard events to the surface even when not focused.
More information about the wayland-devel