nanogui: Support for on-screen keyboard
Subject:
Re: Support for on-screen keyboard
From:
Vidar Hokstad ####@####.####
Date:
16 May 1999 09:14:06 -0000
Message-Id: <Pine.LNX.4.10.9905161014500.2715-100000@a.ncg.net>
On Sat, 15 May 1999, Warner Losh wrote:
> In message ####@####.#### Vidar Hokstad writes:
> : That complicates the server side implementation quite a bit, because you'd
> : have to make sure that nothing that happens in the on-screen keyboard
> : window changes focus - after all you wouldn't want the on-screen keyboard
> : to get the events. That was the entire point of splitting it into two
> : calls.
>
> I don't see how. Can't the server do the GetLastFocusedWindow when
> windowid is zero? No need to do anything else...
Huh? Why would the server do GetLastFocusedWindow()? The server wouldn't
need to do that, since the server would know at all times. And what use
would it have for the value?
> If you had two applications fighting, then you'd have the race.
I don't see how multiple applications will have any bearing here. The
applications get whatever events they are supposed to get, no matter how
many of them there are.
> Also, there is a race from when the mouse click happens until the
> GetLastWindowFocus is called. If in that interval a dialog box pops
> up (say from an alarm going off), then you wouldn't want the dialog
> box to get the event, but you'd want to have the event go to the
> window that had focus when the mouse click happened.
Of the things you've mentioned, I see only one potential problem, and that
is if the user manages to set focus (note: click-to-focus again), move
into the on-screen keyboard, click a button, move out of the on-screen
keyboard, and set focus to another window, all of it _before_ the
on-screen keyboard manages to process the mouse-enter event and do the
GetLastFocusedWindow(). It's not a very likely scenario, but it might
happen, yes.
We can fix that easily, by replacing the GetLastFocusedWindow() with a
call to set the client that owns the on-screen keyboard to receive copies
of all focus events, and let it keep track of it itself. That way, you'd
always have an event queue something like this (only showing the relevant
ones):
focus (windowid)
mouse-enter
mouse-move (x,y)
button-press
Any focus changes occuring at any time before the button-press would be
reflected with a focus event arriving _before_ the button-press event,
and the key event would be sent to that target. It shouldn't introduce any
more code than the other solution.
Regards,
Vidar
