[PATCH 0/2] RFC: Introduce keyboard grabbing and shortcuts inhibitor protocols

[Olivier Fourdan]

Hi,

> 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 [1] and [2], 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 [3] 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.

Cheers,
Olivier

[1] https://bugs.freedesktop.org/show_bug.cgi?id=96547
[2] https://bugzilla.gnome.org/show_bug.cgi?id=752956
[3] https://bugzilla.gnome.org/show_bug.cgi?id=752956#c4