Re: New hint for clients that grab the keyboard

I think that a property on the root window to notify other key grabbing 
clients about the exclusive keyboard status is a very good idea. I did 
mention that it might be a good idea to provide other grabbing clients 
besides the WM an easy way to detect this state, but didn't quite 
realize how important it is in many cases until after posting my message.

Also it's a good thing to define the types of keys that should generally 
be left grabbed, as you did. Of course the list shouldn't be made too 
strict, and there should always be room for user configuration. However 
having some guidelines is good for implementors, so that grave 
inconsistencies that surprise the user too much don't arise.

The "multimedia keys" could be more precisely defined as "local device 
control keys". The set would include volume control, screen brightness 
control and, for example, keys for enabling/disabling touchpads or 
wireless devices. In the general case sending such keys to a remote or 
virtual computer wouldn't make that much sense. And most WMs would 
likely make such things configurable for the user if they want to change 
that behavior.

- Matti

On 09/27/2010 08:42 PM, Dana Jansens wrote:
>
> I'd like to suggest a root window property to pair with this, which is
> set by the Window Manager, similar to _NET_ACTIVE_WINDOW.
>
> Call the property _NET_ACTIVE_WINDOW_EXCLUSIVE_KEYBOARD, it has type WINDOW.
>
> When a window is focused and has _NET_WM_STATE_GRAB_KEYBOARD set, then
> the window manager SHOULD give the application exclusive keyboard
> access.  This means to:
> a) remove all passive KeyGrabs on the root window, except for a
> minimal set to allow removing focus from the selected window via
> keyboard.
> The minimal set of KeyGrabs may only include:
>   - one or more key bindings which the user would use to move focus off
> the window.
>   - one or more key bindings which the user would use to close the window.
>   - any key bindings on "multimedia keys" (a more precise definition of
> these is needed)
>   - any key bindings that include a modifier other than Shift,
> ScrollLock, NumLock, CapsLock, Alt, and Control
>   - any other key binding that the user has explicitly stated should be kept
> b) set the active window's id in the root window property
> _NET_ACTIVE_WINDOW_EXCLUSIVE_KEYBOARD
>
> The value of _NET_ACTIVE_WINDOW must always be equal to
> _NET_ACTIVE_WINDOW_EXCLUSIVE_KEYBOARD at the time
> _NET_ACTIVE_WINDOW_EXCLUSIVE_KEYBOARD is set.
>
> When focus leaves a window which has exclusive keyboard access, or the
> _NET_WM_STATE_GRAB_KEYBOARD state is removed from the active window,
> the window manager MUST take away its exclusive keyboard access.  To
> do this, the window manager will remove the
> _NET_ACTIVE_WINDOW_EXCLUSIVE_KEYBOARD property from the root window.
>
> Applications other than the window manager may hold passive KeyGrabs
> on the root window.  To be compliant, any application which holds a
> passive KeyGrab on the root window, at any time, must listen for the
> _NET_ACTIVE_WINDOW_EXCLUSIVE_KEYBOARD property on the root window.
> When the property is set to a value equal to _NET_ACTIVE_WINDOW, the
> application MUST remove any passive KeyGrabs which do not fall in a
> minimal set of bindings:
>   - any key bindings on "multimedia keys" (a more precise definition of
> these is needed)
>   - any key bindings that include a modifier other than Shift,
> ScrollLock, NumLock, CapsLock, Alt, and Control
>   - any other key binding that the user has explicitly stated should be kept
>
>
>
> What say you all?
>
> - Dana
>
>
>>   Mark
>>
>> On Mon, Sep 27, 2010 at 9:32 AM, Giles Atkinson
>> <[email protected]>  wrote:
>>> Matti,
>>>
>>> An interesting proposal - I would certainly use it.  As a window manager feature, I guess it would also only work for those key/modifier combinations grabbed by the WM.  It's not clear to me how this would handle applets that grab keys for their own use.  One example would be volume controls, although an application like RDP/VNC would probably not want to grab those, it might want to grab the keys of say a workspace pager implemented outside the WM.
>>>
>>> Giles
>>>
>>> -----Original Message-----
>>> From: [email protected] [mailto:[email protected]] On Behalf Of Matti Virkkunen
>>> Sent: 27 September 2010 00:38
>>> To: [email protected]
>>> Subject: New hint for clients that grab the keyboard
>>>
>>> Hi,
>>>
>>> I'd like to propose a new window state hint for applications that
>>> currently grab the entire keyboard.
>>>
>>> Software such as VNC/RDP clients and virtual machine viewers generally
>>> want to grab the entire keyboard when focused, so that everything
>>> (including WM key combinations) can be captured. This however leaves the
>>> user unable to escape the application using the keyboard, e.g. by
>>> switching to another window or desktop. It would be nice if the user
>>> could whitelist some WM key combinations (for example, the key
>>> combinations for switching virtual desktops) so that they work even if
>>> the current window wants to grab most keys.
>>>
>>> XGrabKeyboard is a bit of a drastic measure because it's very difficult
>>> to (or impossible to reliably) exclude some keys from the grab, such as
>>> window manager key combinations. I propose a way to "grab the keyboard"
>>> without using XGrabKeyboard.
>>>
>>> The new window state could be called something like
>>> _NET_WM_STATE_GRAB_KEYBOARD. What it would do is disable all WM key
>>> combinations when the window has input focus, except a user-defined
>>> whitelist. The whitelist could be a part of WM configuration, so that
>>> the same keys work consistently across different apps. When using this
>>> window state, clients wouldn't need to use XGrabKeyboard at all. Clients
>>> can detect the availability of the state via _NET_SUPPORTED and fall
>>> back to using XGrabKeyboard if it's unavailable.
>>>
>>> Rationale for putting this in the WM:
>>>
>>> 1) Usually the WM is what uses the most (if not all) passive grabs on
>>> the user's system.
>>> 2) The WM knows what hotkeys it uses and offers a configuration
>>> interface for them, making it the easiest for the WM to manage the list
>>> of whitelisted hotkeys.
>>> 3) Implementation of this in the WM should be fairly straightforward:
>>> Remove passive grabs when a window in this state receives focus, and
>>> re-grab the keys when focus is lost.
>>>
>>> As a further improvement, a list of hotkeys that work even in grab mode
>>> could be provided as another hint, so that applications can provide a
>>> menu for people to input them into the remote/virtual machine. Some way
>>> of informing the few apps besides the WM that use passive grabs about
>>> the grab state so that they can release/re-grab their keys could also be
>>> considered.
>>>
>>> Related to the issue of switching away from windows that grab the
>>> keyboard I found this feature request:
>>> https://bugs.freedesktop.org/show_bug.cgi?id=4286 , which seems like a
>>> somewhat better way of implementing this. However the last status update
>>> says it's possibly scheduled for "XI2.1" which, at least according to
>>> Google, doesn't even seem to exist yet.
>>>
>>>
>>> - Matti Virkkunen
>>> _______________________________________________
>>> wm-spec-list mailing list
>>> [email protected]
>>> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>>> _______________________________________________
>>> wm-spec-list mailing list
>>> [email protected]
>>> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>>>
>> _______________________________________________
>> wm-spec-list mailing list
>> [email protected]
>> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>>
> _______________________________________________
> wm-spec-list mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/wm-spec-list