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

[Bill Spitzak]

On Thu, Mar 23, 2017 at 12:35 AM, Olivier Fourdan <ofourdan at redhat.com> wrote:
>
> 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.

Of course the clients don't know what shortcuts the wm is using. I
never intended to imply that.

The client knows what shortcuts the CLIENT uses. The reason for this
api is so this information can be communicated to the wm. The client
can say it ignored a keystroke without knowing whether or not the wm
will use it.

> And toolkits do not know that either.

Qt and GTK and FLTK all have a "the widget consumed this event"
indicator that is set or returned after an event is passed to a
widget. I would suspect this is true of all other modern toolkits. A
way to propagate this information back to the wm would make it easy to
cleanly interface such toolkits with the wm.

>> 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

Sorry I'm looking at bug #3 and I do not see anything in the comments
that says you need to emulate keyboard grab exactly. They are saying
that *something* needs to be done (ie the current X on wayland is not
sending any keystrokes to override-redirect windows) but they
certainly are not saying precise emulation is needed. It seems to me
that doing a request for keyboard focus (in Wayland) is all that is
needed. It may also need the easy ability to put the focus back with a
click or mouse enter even if the client does not actively do that.