Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!apollo!oj
From: oj@apollo.uucp (Ellis Oliver Jones)
Newsgroups: comp.windows.x
Subject: Should X11 clients pass on unrecognized KeyPress/Release events?
Message-ID: <38609a0b.d5b2@apollo.uucp>
Date: Mon, 9-Nov-87 14:04:00 EST
Article-I.D.: apollo.38609a0b.d5b2
Posted: Mon Nov  9 14:04:00 1987
Date-Received: Wed, 11-Nov-87 06:45:42 EST
Organization: Apollo Computer, Chelmsford, Mass.
Lines: 63

This is a question about whether X11 client programs should be "encouraged"
to do something special with function keys they don't know how to handle.

( Please don't mistake this question as discussion of whether clients
  should be REQUIRED to do this.  Obviously they shouldn't.  If there's
  something about this proposal that won't work unless all clients
  are forced to comply, then this proposal is wrong. )

X11 clients which select KeyPress and/or KeyRelease events could adopt
the discipline of dealing with every keystroke as follows:

    (a) determining the Keysym of the key involved (with
        XLookupString, XLookupKeysym, or equivalent)
    (b) determining whether the key involved has
        any meaning in the context of the human interface
        of the application receiving it.
    (c) If the key has no meaning locally, the client would pass
        the event up the window hierarchy (using XSendEvent
        to resend it to the parent window, and specifying propagate)

If applications were encouraged to do this, a significant advantage
would be realized:  Window-managers and other "workstation control" clients
could select KeyPress and KeyRelease events in root windows;  they could
assign function keys to operations such as window circulation.

It's worth "encouraging" clients in this way ... most applications will
use some toolkit routine/widget to read text.  If the majority of
text toolkits comply, then application code has little to do.

Under this proposed scheme, clients with windows would pass on function keys they
knew nothing about while "swallowing" the events for keys they understand.

This gets away from the need to do XGrabKey requests against root windows, and
still provides global function-key capability.  In other words, window
managers can be activated with function keys, while simultaneously leaving
those keys available for application human interfaces.  Key-assignment
conflicts between window managers and applications would be greatly reduced.

Non-compliant clients would not break things fatally...they would merely
interfere with global function keys when they had the focus
and/or contained the pointer.

A couple of questions of details...
(a) should clients always pass on modifier key transitions, so
    that the trickle-up recipients could get them?
(b) what about compose sequences?
(c) Perhaps unknown  keys should be passed directly to the
    root window, rather than to the parent window.  This
    would be easier in one respect; the keyboard event structure
    tells you the root window ID.

Doubtless the main disadvantage of this approach is the performance impact
(especially if all modifier key events must get propagated).

A secondary disadvantage is that some applications might get
royally fouled up if they were to receive edited streams of key-transition
events; detail (c) above might be a way to mitigate this effect, because
clients selecting key events on the root window  might (??) reasonably be
expected to be less keyboard-stream oriented.

Suggestions, remarks?  Flames to /dev/null (or to me...spare the newsgroup!)
Ollie Jones             617-256-6600 x 7410
Apollo Computer, Inc.   oj@apollo.com  {brunix, umix, ulowell, decvax}!apollo!oj