On Mon, Sep 27, 2010 at 1:16 PM, Mark Tiefenbruck <m...@fluxbox.org> wrote: > I don't have any thoughts on a standard, but I'll mention how Fluxbox > handles this for inspiration. The user can precede keyboard shortcuts > in the config file by a namespace, and he can create commands that > switch the set of keyboard shortcuts that are currently in effect. > I've been using this for years to disable all but a few shortcuts when > using Xnest or Xephyr. Our users also use it to enter a window moving > or resizing mode, for example, so they can reuse simple keystrokes > depending on the task they want to perform. I guess the key addition > you want to make here is that the window manager should be able to > change namespaces when a particular window is focused (users who have > read our source could do this, as there are event hooks to run > commands when the focus changes; we don't advertise this feature > because of all the stupid things you could do with it), and for > applications that grab the keyboard to let the window manager handle > it (maybe we could add something to _NET_WM_SUPPORTED).
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 > <giles.atkin...@eu.citrix.com> 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: wm-spec-list-boun...@gnome.org [mailto:wm-spec-list-boun...@gnome.org] >> On Behalf Of Matti Virkkunen >> Sent: 27 September 2010 00:38 >> To: wm-spec-list@gnome.org >> 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 >> wm-spec-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/wm-spec-list >> _______________________________________________ >> wm-spec-list mailing list >> wm-spec-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/wm-spec-list >> > _______________________________________________ > wm-spec-list mailing list > wm-spec-list@gnome.org > http://mail.gnome.org/mailman/listinfo/wm-spec-list > _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
