nanogui: Thread: Support for on-screen keyboard - SUMMARY

To summarize, here's an updated suggestion, based on Alex' suggestion,
with a few modifications by me, and a change prompted by Warners concerns:

  - We don't guarantee that on-screen keyboards will work properly with
     a mouse as a pointing device unless you use "click to focus".
     For a touchpad other focus mechanisms (including the present)
     should work just fine, since you typically would lift whatever
     it is you touch the screen with, and move it to the on-screen
     keyboard in one movement.
  
  - An on-screen keyboard "registers" itself with the NanoX server
    by calling a SendCopiesOfAllFocusEventsToMe() (preferrably with
    a shorter name :-) type function. This is done _instead_ of the
    on-screen keyboard itself requesting the ID of the last focused
    window, to ensure that the last focus id that the on-screen keyboard
    records before a button on it is pressed is always the last one to
    actually happen before the button press (removing a potential
    race situation, jfr. Warners mails).

    This require:
       * A small command to be added to the server to register the 
          on-screen keyboard client as receiver of server wide focus
          events.
       * A small change to the command that generate focus events to
          send a copy to any client registered to receive server
          wide events.

  - The on-screen keyboard then sits and waits for focus events, and
     as long as it is focus events for other windows than itself, it
     updates it's last-focused flag. Whenever it receive a button press
     over one of it's keys, it then calls a "SendKeyEvent()" type
     function, with the last-focused windowid, the key, and any modifiers
     as arguments.

     This require:
        * A command to be added to the server to send key events
           to the server, that will then resend the key event to
           the specified window.

Anyone that sees problems, or have suggestions for changes to this
modified suggestion?

If not, I'll go ahead and write a simple test implementation of it.

Regards,
Vidar

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

On Sun, 16 May 1999, Vidar Hokstad wrote:
>     This require:
>        * A small command to be added to the server to register the 
>           on-screen keyboard client as receiver of server wide focus
>           events.
>        * A small change to the command that generate focus events to
>           send a copy to any client registered to receive server
>           wide events.

We probably want something along this line for the window manager, so it
can alter the border appearance for the currently focussed window.

>   - The on-screen keyboard then sits and waits for focus events, and
>      as long as it is focus events for other windows than itself, it
>      updates it's last-focused flag. Whenever it receive a button press
>      over one of it's keys, it then calls a "SendKeyEvent()" type
>      function, with the last-focused windowid, the key, and any modifiers
>      as arguments.
> 
>      This require:
>         * A command to be added to the server to send key events
>            to the server, that will then resend the key event to
>            the specified window.
> 
> Anyone that sees problems, or have suggestions for changes to this
> modified suggestion?

Sounds okay, but I have to say I also quite like the idea now of having a
special value (which can never be a real window ID, like -1 or something)
for the SendKeyEvent() call which tells the server to send it to the last
focussed window.

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

On Sun, 16 May 1999, Alex Holden wrote:

> On Sun, 16 May 1999, Vidar Hokstad wrote:
> Sounds okay, but I have to say I also quite like the idea now of having a
> special value (which can never be a real window ID, like -1 or something)
> for the SendKeyEvent() call which tells the server to send it to the last
> focussed window.

But do we really want to have the server handle the window of the
on-screen keyboard as a special case. Remember that the on-screen keyboard
could very well have sub-windows etc., which would mean that  to be sure
that the server doesn't keep track of the _wrong_ windowid for focus,
it would have to know that it should ignore any focus changes caused by
pointer movements over the on screen keyboard.

It's a minor thing, but the focus notification mechanism would buy you
exactly the same functionality, would be reusable for window management,
and may also let the on-screen keyboard choose to ignore certain windows
if you wish, instead of adding even more stuff to the server.

Anyway, this isn't mutually exclusive, and since we can use the focus
notification anyway, I think I'll look into writing a test based on that
first, then it would be a minor issue to add a special ID to the
SendKeyEvent() function later if we need it.

Regards,
Vidar

On Sun, 16 May 1999, Vidar Hokstad wrote:
> Anyway, this isn't mutually exclusive, and since we can use the focus
> notification anyway, I think I'll look into writing a test based on that
> first, then it would be a minor issue to add a special ID to the
> SendKeyEvent() function later if we need it.

I was just thinking that. Code it both ways, and keep the one which works
best...

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