Re: New hint for clients that grab the keyboard

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


On Mon, Sep 27, 2010 at 9:32 AM, Giles Atkinson
<Giles Atkinson 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-bounces gnome org [mailto:wm-spec-list-bounces 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:
> , 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
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]