nanogui: Support for on-screen keyboard
Subject:
Re: Support for on-screen keyboard
From:
Vidar Hokstad ####@####.####
Date:
15 May 1999 14:30:02 -0000
Message-Id: <Pine.LNX.4.10.9905151612190.2715-100000@a.ncg.net>
On Sat, 15 May 1999, Alexander Peuchert wrote:
> How do you think of handling a mouse, a keyboard and a on-screen keyboard
> simultaniously ?
Both the "mouse" (it could be any pointing device, including a touch
screen) and the regular keyboard would still work as before: It's events
would still be generated independently of client generated events,
and will still be sent to whatever window has focus.
The only change would be that widgets sets that choose to support it could
call a function to set the (server wide) default for _client generated_
keyboard events. If no on-screen keyboard is running, everything works as
usual.
If you then start an on-screen keyboard client, the on screen keyboard
will call a function to generate a keyboard event whenever you use a
mouse or a touch screen or whatever to point and click on it.
Only when a keyboard event is generated that way, instead of being sent to
whatever window has focus it will send the event to whatever window has
been set as the default target by the widget set.
Another good reason for placing the on-screen keyboard in a separate
application is that requirements can be very diverse... Some may prefer a
Grafitti (PalmPilot) type interface - or that new Grafitti replacement -,
some want only a basic Qwerty or Dvorak keyboard, some want Japanese,
Russian, Greek etc. Having it in a separate application means that you can
drop it totally, or you can choose an on-screen keyboard application that
is tailored to your needs, instead of having to track down or write a
widget set that handles whatever type of on-screen keyboard you'd like.
Regards,
Vidar
