nanogui: Support for on-screen keyboard
Subject:
Re: Support for on-screen keyboard
From:
Warner Losh ####@####.####
Date:
15 May 1999 21:45:18 -0000
Message-Id: <199905152140.PAA61922@harmony.village.org>
In message <Pine.LNX.4.04.9905151929020.415-100000@hyperspace> Alex Holden writes:
: The focus is on the keyboard client when you are using it to select a key.
: When the keyboard client decides what keypress it wants to send, it simply
: does something like GrSendKey(key, GrLastGCId());. If the focus changes
: between the keyboard client deciding what key you just selected (I suppose
: it could happen if you had a slow handwriting recognition algorithm to
: process or something), all that would happen is that the key event would
: get sent to the keyboard client, which would ignore it. Big deal. You
: shouldn't have changed focus before the keyboard client finished
: processing the keypress anyway. It's not a race condition at all.
Yes, it is a race condition. It is a problem, and has been a problem
with past systems. Granted, it isn't a race that you'll lose often,
but it will be a race that is lost. Trust me on this. I did low
level X and WinNT event processing dispatching code in OI and found
many race conditions in X and the Win32 API that did cause problems
from time to time.
You also have the "dialog box" problem. If I have a dialog box appear
when I'm typing something in, do I want it to get what input events,
or do I want the keyboard to go away breifly while the dialog box is
processed.
: > Why not just SendKeyEvent(...)? Maybe with a WindowID of 0 to mean
: > current focus. That way there can be no race condition.
:
: That's not what we want. That would send it to the keyboard client, not
: the text area you were trying to enter text into.
The keyboard application should not take keyboard focus.
Warner
