nanogui: Support for on-screen keyboard


Previous by date: 15 May 1999 21:41:56 -0000 Re: Support for on-screen keyboard, Vidar Hokstad
Next by date: 15 May 1999 21:41:56 -0000 Re: Support for on-screen keyboard, Warner Losh
Previous in thread: 15 May 1999 21:41:56 -0000 Re: Support for on-screen keyboard, Vidar Hokstad
Next in thread: 15 May 1999 21:41:56 -0000 Re: Support for on-screen keyboard, Warner Losh

Subject: Re: Support for on-screen keyboard
From: Warner Losh ####@####.####
Date: 15 May 1999 21:41:56 -0000
Message-Id: <199905152137.PAA61901@harmony.village.org>

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...

:  - GetLastFocusedWindow() would be called on _each_ mouse-enter event
:     to the window.
:  - Events that would generate a SendKeyEvent() (button clicks in the
:     on-screen keyboard) can only happen between the mouse-enter and
:     the mouse-leave event, and any focus changes that happens then is
:     an internal matter for the on-screen keyboard. Those focuse changes
:     _should_ be ignored, which is why we do the GetLastFocusedWindow()
:     on mouse-enter, and not not right before SendKeyEvent()
:  - Other focus changes can only happen _after_ a mouse-leave, and then
:     they will be reflected by the GetLastFocusedWindow() that happens
:     when the pointer reenters the on-screen keyboard window.

If you had two applications fighting, then you'd have the race.  In
addition, the keyboard application isn't guaranteed that it won't get
prempted by another process which might take the focus (or run until
the focus has changed, get its stuff, start to process it, only to
find that the "old" event went to the wrong place).

This is a race, and it will bite you.  I've been there and done that
and know what I'm talking about.  Desiging for a single user only
(with the implicit only one process active at a time) is going to lead
to trouble.

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.  And for that
you'd need a timestamp (and a history in the server).

Warner

Previous by date: 15 May 1999 21:41:56 -0000 Re: Support for on-screen keyboard, Vidar Hokstad
Next by date: 15 May 1999 21:41:56 -0000 Re: Support for on-screen keyboard, Warner Losh
Previous in thread: 15 May 1999 21:41:56 -0000 Re: Support for on-screen keyboard, Vidar Hokstad
Next in thread: 15 May 1999 21:41:56 -0000 Re: Support for on-screen keyboard, Warner Losh


Powered by ezmlm-browse 0.20.