Patch for keyboard handling

[Takuma Murakami]

Harold,

> I think I understand your original patch better now and I think that you 
> were probably doing it correctly, but I can't verify that right now.  If 
> this is what you were trying to do, then it probably is correct:
> 
> 1) Assume that no keyboard input is in the mi queue when winWindowProc 
> is called.
> 
> 2) If we are getting the keyboard focus, grab the Windows mode key state 
> and X mode key state, compare them, and send fake key presses to X to 
> get the two states in synch.
> 
> 3) Do not synch the key states anywhere else.
> 
> That would probably work because it would enqueue key messages that will 
> synch the mode key states before placing normal key messages in the 
> queue.  Thus, when we ask X for the mode key states we should get a 
> consistent result since the input queue in X is empty.

The all points are right.  I think you completely
understand this patch.  The essential difference between
the old code and this patch is to remember states by
ourselves or to peek in the internal states if necessary.
Moreover, the old code refers the states of Windows
which is not guaranteed to same as the XWin's states.

Hence I believe the patch is, at least, not worse than
the old code, though there remains some incompleteness.
One is the event queue you told, another is cooperation
with customized keyboards.

> Does that sound like what you were trying to do initially?  I got 
> confused because I couldn't keep track of where all the calls to 
> winRestoreModeKeyStates would up.

winRestoreModeKeyStates is called from WM_SETFOCUS
handlers in winTopLevelWindowProc (in -multiwindow
case) and winWindowProc (in other cases).  Only 2 places.

I hope this helps your review.

Takuma Murakami (murakami@ipl.t.u-tokyo.ac.jp)