On 09/27/2010 11:54 PM, Dana Jansens wrote:
On Mon, Sep 27, 2010 at 4:41 PM, Matti Virkkunen<mvirkku...@gmail.com> wrote:
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.
Yes, I saw that also, it was a good idea.
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.
I disagree with this part.. I think the list should be quite strict.
Leaving it vague means that an application programmer has absolutely
no idea what keys they can expect to have access to, making the whole
thing rather useless as they will likely resort to a keyboard grab
anyways. Even now it is a little vague, but I think it will work for
most users, and should be clear what is happening if a key press is
used by the WM instead (i.e. moving focus or closing the application).
Stating that any other key bindings are allowed, if the user has
explicitly chosen them, means at least the user will know why their
key shortcuts are not working in applications. And this leaves
freedom for a user to configure things how they wish, instead imposing
limitations only on default configurations so that application
developers know what to expect.
All right, I can see your point now. It would be a bit difficult to code
for the case where you can't trust that any key combination will reach
you. Formalizing a strict list of default keys to reserve for the WM
only might end up being somewhat difficult, though, because in many
cases very basic functionality such as closing a window might be
expected to be redirected to a remote machine by default.
My suggestion (the small footnote in my original message) about
notifying clients about the list of keys that have been "high priority
grabbed" by the WM (or other clients) might help to code so that user
configuration is taken into account. As an example from something that
does grabbing on two levels, Windows remote desktop clients will
invariably have an alternate way to send "Ctrl-Alt-Del" because that's a
key combination that's exclusively grabbed by the OS. In our case we'd
just have some more key combinations that clients will be able to
discover, and display in, for example, a menu.
I can see a few problems with this, though, mainly the list growing very
large and the possible need to make the list of keys descriptive (so
that clients that want to give users the opportunity to input those
combinations can display a more user-friendly UI for doing that).
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.
It includes slightly more than this, also keys like "check email" and
"play/pause" etc. There are keysym names for them X11, which we could
list, but I expect there may be some formal name for the whole group
of them. Either way it should be clear exactly which keys are
included or not, for reasons stated above.
"Check email" and "play/pause" are keys that might make sense (at least
more sense than, say, "disable touchpad") to send to a remote/virtual
machine that's being used for normal desktop use, however they are on
kind of a grey zone. I'm sure there are lots of opinions on these things.
At any rate, if this ever makes its way further towards becoming a part
of some standard, formalizing the default lists of keys (WM keys and
multimedia keys and whatnot) will probably require quite a bit of open
discussion. It's a delicate balance between convenience in the common
case and not doing things that are too unexpected in the uncommon case.
- Matti
Cheers,
Dana
- 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
<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
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
