[comp.windows.news] X11/NeWS keyboard stuff

don@CS.UMD.EDU (Don Hopkins) (10/26/89)

...In NeWS 1.1 you can look at the "KeyState" array in events to see
which keys were down when the event happened, and you'll see the
symbolic names of the shift keys that were down (/Control, /Shift,
/LeftShift, etc...), due to the way keyboard translation is handled by
a central process, which translates the raw key codes in the Names of
hardware-generated events to ascii and symbolic values, and
redistributes the events to the input focus.

In X11/NeWS, the keyboard translation isn't handled by a global
process -- each keyboard client (more efficiently) does its own
translation (via ClassKeysInterest), so the translated names don't end
up going through the event queue (thus the symbols don't make it into
the event KeyState array).

[I think the way the KeyState array works is that it contains the Name
of every event that had gone by with an Action of /DownTransition,
without a matching event with an Action of /UpTransition. So you could
send a Name=/LeftEyelid, Action=/DownTransition event by hand, and the
name /LeftEyelid would appear in the KeyState array of delivered
events until you sent out a Name=/LeftEyelid, Action=/UpTransition
event. NeWS Puzzle: write an event manager that translates
{Left,Right}Eyelid {Up,Down}Transition events into higher level /Wink
and /Blink events.]

So if you use ClassKeysInterest, the keyboard events are delivered to
you directly, instead of indirecting through a keyboard translation
process as with addkbdinterests. X11/NeWS has a LiteUI compatibility
package that LiteUI clients use via the old addkbdinterests, which
forks off its own personal (or is it shared?) keyboard translation
manager, that translates and redistributes the events to the LiteUI
client. (There's also some amazing stuff for doing selection event
translation.) The LiteUI compatibility manager expresses a
ClassKeysInterest, and sends the translated keyboard events through
the event queue, so their translated symbolic names make it into the
KeyStates array, that shows up in every delivered event, for any NeWS
process to see. But they won't ever be there unless you're running
something that's using the old LiteUI compatibility package (or
anything that sends translated keyboard events through the event
queue).

If you just use "bindkey" in X11/NeWS to bind a function key to a
procedure that looks in its triggering event's KeyState for the
symbols /Control, /Meta, /Shift, or whatever, all you will see will be
the untranslated key codes (big meaningless numbers, not ascii values
or symbolic names) that are down, *unless* you're running some NeWS
1.1 application that uses "addkbdinterests". So I think it's a bad
idea to depend on symbolic or ascii values showing up in the /KeyState
array of an event. Just do the translation from symbols to key codes
yourself, ala "/keyforsymbol ClassKeyboard send", and look for the key
codes in the KeyState array. So an X11/NeWS version of keypad.ps
probably couldn't get away with the symbolic key name constants in the
case statement, and could probably just use a dictionary mapping the
shift key codes (looked up at load time) to procedures instead.  Or
maybe there's a suclass of ClassKeysInterest that could help with
this...

LiteUI was one of the most confusing parts of NeWS 1.1, but I must say
that the keyboard and selection UI code in X11/NeWS is *much* nicer!
(it's still confusing, but quite an improvement!) It's all object
oriented, and it separates the user interface from the programmer
(application) interface. You can switch to a totally different user
interface style on the fly without running applications noticing!
(Like a different selection policy [SunView's point/extend -vs- Mac's
drag through], focus policy [focus follows cursor -vs- the dreaded
click to type], window manager [Open Look -vs- Close Feel], etc...)

I may be completely confused or deluded (so please correct me where
I'm wrong!), or just plain boring (so hopefully you haven't read this
far), but I'm typing this in to help anyone having similar problems
porting NeWS 1.1 applications to X11/NeWS, and to start some
discussion along those lines.

	-Don