oj@apollo.uucp (Ellis Oliver Jones) (11/09/87)
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!ojKimbrough@dsg.csc.ti.COM (Kerry Kimbrough) (11/10/87)
I think your proposal is reasonable, but I'm dubious about its goal:
...window managers can be activated with function keys, while
simultaneously leaving those keys available for application human
interfaces.
It's at least debatable whether this is good UI policy. The possibility for mode
errors ("But I thought I was talking to the window manager!") is too great.
Also, I'm concerned about the handling of typographical errors. If an
inappropriate keystroke is just passed up the line, my typo may accidentally
provoke an action that is harmful, irreversible, or perhaps just unnoticed.
Rather that pursuing this approach, I'd look for solutions that are more robust
and have better human factors.deboor@dill.Berkeley.EDU.berkeley.edu (Adam R de Boor) (11/11/87)
I do not think it is reasonable for clients to pass on KeyPress/Release events, because there is no need, if the window manager is written properly. There are grab modes associated with each passive grab that can cause the keyboard or pointer to freeze, as far as clients are concerned. A window manager that wishes to only grab a key (or button) in a given context can place a passive grab on that key/button with the mode of the device (keyboard or pointer) set to synchronous. If it decides it wants the event, it simply unfreezes the device and processing continues normally. If it doesn't want the event, it unfreezes the event in Replay mode (ReplayKeyboard or ReplayPointer). That, I think, will cause the event to be regenerated ignoring the passive grab. I.e. the event will be sent to the appropriate window. I've been wrong about this synchronous stuff before, but I believe this is the "proper" way to handMDmissc6!t"T", ".cm
oj@apollo.uucp (Ellis Oliver Jones) (11/13/87)
In article <21715@ucbvax.BERKELEY.EDU> deboor@dill.Berkeley.EDU.UUCP (Adam R de Boor) writes: > A window manager that wishes to only grab a key (or button) ... can >place a passive grab on that key/button. ... >If it decides it wants the event, it simply unfreezes the device... >If it doesn't want ... the event, it unfreezes the event in Replay mode... Right, but this gives the window manager "first dibs" at the event; in other words the window manager's grabs can still foul up the application's human interface. A goal of my proposal is to give the application "first dibs." In another article Kimbrough%dsg.csc.ti.com@RELAY.CS.NET (Kerry Kimbrough) writes: >It's at least debatable whether this is good UI policy. The possibility for mode >errors ("But I thought I was talking to the window manager!") is too great. Point well taken. To counter it: (1) it's a shame to rule out certain UI policies. "Mechanism, not policy." (2) Applications (WMs) that honor keystrokes from the root windows should be careful to constrain the semantics of those keys (this is, arguably, sound human interface design regardless of the merits of resending key events) -- their action, if any, should "echo" immediately. This way, no action can go unnoticed. For example, a "Circulate Windows" key would change the stacking order while the user watched. -- single keystrokes should stand alone. Such a "global" keyboard interface had best be modeless. -- they should do non-destructive things (in general, there should be some sort of "confirm" dialog on irreversible actions invoked by single keystrokes). Actions like "iconify" and "circulate window" meet these requirements. A third objection, raised by my colleague John Francis, is that there is, in any protocol that involves resending events, the inherent possibility for keystrokes arriving out of order at their ultimate destination. That could be quite a nasty problem. Perhaps an extension to X11 is in order. This extension would provide a new type of keyboard event. Solicitations of this new keyboard event would include a specification of a keymask in the solicitation request. Remarks? /oj