nanogui: Thread: Support for on-screen keyboard

To be attractive for use with set-top boxes etc, NanoX will need support
for some sort of on-screen keyboard...

It can be a separate client, as long as we add a command to
generate keypress events. That's the easy part. But we also
need a sensible way of knowing what window to target with the
events, since the mouse pointer will be over the onscreen keyboard,
and we don't want that to receive the events it generates.

My idea so far, is to add another command to set the default target for 
client generated keyboard events, and expect widget sets to call
that function whenever some widget is activated (by whatever definition
the widget set has for "activating" a widget, for instance by clicking in
a text entry field).

It wouldn't make sense to go through any efforts to handle typical 
keyboard shortcuts, since it wouldn't really be any shortcut anymore on
an on-screen keyboards :-)

Any good suggestions?

Vidar Hokstad ####@####.####
Director of R&D, Screen Media AS

On Sat, 15 May 1999, Vidar Hokstad wrote:

> To be attractive for use with set-top boxes etc, NanoX will need support
> for some sort of on-screen keyboard...
> 
> It can be a separate client, as long as we add a command to
> generate keypress events. That's the easy part. But we also
> need a sensible way of knowing what window to target with the
> events, since the mouse pointer will be over the onscreen keyboard,
> and we don't want that to receive the events it generates.
> 
> My idea so far, is to add another command to set the default target for 
> client generated keyboard events, and expect widget sets to call
> that function whenever some widget is activated (by whatever definition
> the widget set has for "activating" a widget, for instance by clicking in
> a text entry field).
> 
> It wouldn't make sense to go through any efforts to handle typical 
> keyboard shortcuts, since it wouldn't really be any shortcut anymore on
> an on-screen keyboards :-)
> 
> Any good suggestions?

Shoudn't this go into a toolkit lib? For example, a text-field with
optional on-screen keyboard. This way, the nano-x can be kept nano.

> 
> Vidar Hokstad ####@####.####
> Director of R&D, Screen Media AS
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

- alex

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

On Sat, 15 May 1999, Alexander Peuchert wrote:

> Shoudn't this go into a toolkit lib? For example, a text-field with
> optional on-screen keyboard. This way, the nano-x can be kept nano.

I don't see any reason why my two suggested commands would cause much
bloat. We're talking about ~20 lines of code here: One function to
generate a keyboard event (which we should have anyway, IMHO) from
a client, and one function to set the default window id to send the
client generated event to, if none was specifically added.

That would make it easy to add on-screen keyboard support to any
widget set by adding _one_ function call to set the default target
wherever the widget set handles activation of a widget type that should
take keyboard input, instead of having to integrate a full on-screen
keyboard application into every toolkit in order to support it.

It would then allow the user or the developer to freely choose any
on-screen keyboard application made available for Nano-X, instead of
being stuck with whatever on-screen keyboard included in the toolkit you
use. 

But of course it's easy to provide a define to specify whether those two
commands will be included or not.

Regards,
Vidar

On Sat, 15 May 1999, Vidar Hokstad wrote:

> On Sat, 15 May 1999, Alexander Peuchert wrote:
> 
> > Shoudn't this go into a toolkit lib? For example, a text-field with
> > optional on-screen keyboard. This way, the nano-x can be kept nano.
> 
> I don't see any reason why my two suggested commands would cause much
> bloat. We're talking about ~20 lines of code here: One function to
> generate a keyboard event (which we should have anyway, IMHO) from
> a client, and one function to set the default window id to send the
> client generated event to, if none was specifically added.
> 
> That would make it easy to add on-screen keyboard support to any
> widget set by adding _one_ function call to set the default target
> wherever the widget set handles activation of a widget type that should
> take keyboard input, instead of having to integrate a full on-screen
> keyboard application into every toolkit in order to support it.
> 
> It would then allow the user or the developer to freely choose any
> on-screen keyboard application made available for Nano-X, instead of
> being stuck with whatever on-screen keyboard included in the toolkit you
> use. 

How do you think of handling a mouse, a keyboard and a on-screen keyboard
simultaniously ?

Sorry, but I don't have more time to think about it ...

> 
> But of course it's easy to provide a define to specify whether those two
> commands will be included or not.
> 
> Regards,
> Vidar
> 
> 

- alex

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

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

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 ;-) )

On Sat, 15 May 1999, Vidar Hokstad wrote:
> To be attractive for use with set-top boxes etc, NanoX will need support
> for some sort of on-screen keyboard...

I don't know about set top boxes (don't you use a remote control for
them?), but palmtops certainly need this. Have you seen
http://www.mrl.nyu.edu/perlin/demos/quikwriting.html ? I think it's pretty
cool, it seems strange at first, but it's not too bad apart from the lack
of symbols and control keys once you get used to it.

> It can be a separate client, as long as we add a command to
> generate keypress events. That's the easy part. But we also
> need a sensible way of knowing what window to target with the
> events, since the mouse pointer will be over the onscreen keyboard,
> and we don't want that to receive the events it generates.

How about a call which sends a key event to the window which was last in
focus? Or a combination of a call which returns the ID of the last window
which was in focus and another call which sends a keyboard event to a
specified window?

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Sat, 15 May 1999, Alex Holden wrote:

> On Sat, 15 May 1999, Vidar Hokstad wrote:
> > To be attractive for use with set-top boxes etc, NanoX will need support
> > for some sort of on-screen keyboard...
> 
> I don't know about set top boxes (don't you use a remote control for
> them?), but palmtops certainly need this. Have you seen
> http://www.mrl.nyu.edu/perlin/demos/quikwriting.html ? I think it's pretty
> cool, it seems strange at first, but it's not too bad apart from the lack
> of symbols and control keys once you get used to it.
> 
> > It can be a separate client, as long as we add a command to
> > generate keypress events. That's the easy part. But we also
> > need a sensible way of knowing what window to target with the
> > events, since the mouse pointer will be over the onscreen keyboard,
> > and we don't want that to receive the events it generates.
> 
> How about a call which sends a key event to the window which was last in
> focus? Or a combination of a call which returns the ID of the last window
> which was in focus and another call which sends a keyboard event to a
> specified window?

How about excluding some windows from getting focus ?

> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

- alex

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

On Sat, 15 May 1999, Alexander Peuchert wrote:
> How about excluding some windows from getting focus ?

If it doesn't have focus, it won't get the mouse events it needs to read
what you are scribbling onto it.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Sat, 15 May 1999, Alex Holden wrote:

> On Sat, 15 May 1999, Alexander Peuchert wrote:
> > How about excluding some windows from getting focus ?
> 
> If it doesn't have focus, it won't get the mouse events it needs to read
> what you are scribbling onto it.

I meant keyboard focus ...

> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 

- alex

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