nanogui: Support for on-screen keyboard


Previous by date: 15 May 1999 14:35:56 -0000 Re: Support for on-screen keyboard, Vidar Hokstad
Next by date: 15 May 1999 14:35:56 -0000 Re: Support for on-screen keyboard, Alex Holden
Previous in thread: 15 May 1999 14:35:56 -0000 Re: Support for on-screen keyboard, Vidar Hokstad
Next in thread: 15 May 1999 14:35:56 -0000 Re: Support for on-screen keyboard, Alex Holden

Subject: Re: Support for on-screen keyboard
From: Alexander Peuchert ####@####.####
Date: 15 May 1999 14:35:56 -0000
Message-Id: <Pine.GSO.4.02.9905151627110.26163-100000@rumburak>

On Sat, 15 May 1999, Vidar Hokstad wrote:

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

Okay, but how could this look for the user ? If he clicks on a textfield,
it will get the keyboard focus. So, the screen-keyboard will get the focus
everytime you type something on it ...

How do you plan to figure out the reciever of the screen-keyboard events...

I see more API here.

- alex

> 
> Regards,
> Vidar
> 
> 

- alex

Alexander Peuchert
####@####.####
http://www.peuchert.de ( not very interesting yet ;-) )


Previous by date: 15 May 1999 14:35:56 -0000 Re: Support for on-screen keyboard, Vidar Hokstad
Next by date: 15 May 1999 14:35:56 -0000 Re: Support for on-screen keyboard, Alex Holden
Previous in thread: 15 May 1999 14:35:56 -0000 Re: Support for on-screen keyboard, Vidar Hokstad
Next in thread: 15 May 1999 14:35:56 -0000 Re: Support for on-screen keyboard, Alex Holden


Powered by ezmlm-browse 0.20.