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

[Bill Spitzak]

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.

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.

On Wed, Mar 22, 2017 at 9:27 AM, Olivier Fourdan <ofourdan at redhat.com> wrote:
> [Resending because I sent to wayland-devel-bounce by mistake -facepalm-]
>
> Hi,
>
> This is a follow-up on my previous attempt to add a keyboard grabbing
> protocol for Xwayland [0].
>
> While I had the previous iteration working in Xwayland and mutter, this
> was clearly not acceptable for Wayland native windows.
>
> So I reckon we actually need two protocols, one specifically for Xwayland
> and another one for Wayland native clients.
>
> The one for Xwayland allows to re-route keyboard events to a given surface
> even when the surface doesn't have actual keyboard focus. This is needed
> for X11 applications that map an override redirect window (thus never
> actually focused by the window manager) but issueing an active grab on
> the keyboard to capture all keyboard events. An example of this is
> xscreensaver unlock dialog [1] or gksu [2]
>
> The second protocol is simpler, in the sense that it will simply tell the
> Wayland compositor to ignore its own keyboard shortcuts when a given surface
> is focused. A typical use case for this is virt-viewer/virt-manager where the
> typical window manager shortcuts should be send to the remote host rather
> than being caught and handled by the local Wayland compositor [3].
>
> I have sample implementations of these two protcols in Xwayland, mutter
> and gtk+ and it seems to work well, for both cases (x11 O-R window under
> Xwayland and virt-viewer using Wayland native).
>
> Cheers,
> Olivier
>
> [0] https://lists.freedesktop.org/archives/wayland-devel/2016-August/030863.html
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=96547
> [2] https://bugzilla.gnome.org/show_bug.cgi?id=752956
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1285770
>
> Olivier Fourdan (2):
>   Introduce keyboard grabbing protocol for Xwayland
>   Add keyboard shortcuts inhibitor
>
>  Makefile.am                                        |   2 +
>  configure.ac                                       |   2 +-
>  unstable/keyboard-shortcuts-inhibit/README         |   4 +
>  .../keyboard-shortcuts-inhibit-unstable-v1.xml     |  85 +++++++++++++++++
>  unstable/xwayland-keyboard-grab/README             |   4 +
>  .../xwayland-keyboard-grab-unstable-v1.xml         | 101 +++++++++++++++++++++
>  6 files changed, 197 insertions(+), 1 deletion(-)
>  create mode 100644 unstable/keyboard-shortcuts-inhibit/README
>  create mode 100644 unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
>  create mode 100644 unstable/xwayland-keyboard-grab/README
>  create mode 100644 unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
>
> --
> 2.9.3
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel