detailed review of GOK

[Bill Haneman]

Hi Henrik:

The reason that StickyKeys is needed is not only because of general key 
combinations like the one you mention (Control-Alt-X) but also because 
of the interaction with CapsLock, etc.  In general the only  way to 
accurately reflect what the X server will do with key events is to ask 
the x server, so the client application can't do a good job of 
simulating the real physical keyboard without StickyKeys.  I suppose a 
"mostly works" equivalent could be provided without StickyKeys, but it 
would not work with all applications and the resulting bugs would be 
very confusing to explain to the user.  Since XKB and StickyKeys are 
available on virtually every X platform now, it makes sense to just 
require it.  However, the sticky keys notification dialog still makes 
sense IMO, because any client which causes the user's physical keyboard 
to behave differently should probably let the user know about it.

>> In a number of cases, there are dependencies which no client program 
>> attempting to do what GOK is doing can avoid.  StickyKeys is a case 
>> in point; it is not technically feasible to implement 
>> sticky-keys-like functionality in the client alone. 
>
> Is that because we are talking about a very general implementation 
> that can feed any key combination (Ctrl-Alt-X) to any part of the 
> desktop? I guess just providing for upper case ( and [ * & etc.) would 
> be easier (but not as useful).
>
>> Likewise, it is not technically possible to make a reliable 
>> point-and-click onscreen keyboard using the system core pointer, 
>> using today's X server and widget toolkits.
>
> Hm. I seem to remember using GTKeyboard some time ago on a tablet PC 
> with much less fuss. I think that is GTK1 though, and probably won't 
> compile with Gnome 2.

I think you would find that GTKeyboard acted oddly or failed to work at 
all with certain key combinations.  For instance, if you invoke a menu 
using a keyboard shortcut, GTKeyboard would stop working; there are many 
similar situations where a simple point-and-click keyboard using the 
core pointer is bound to fail.    There are two reasons; in some cases 
the pointer will be grabbed by another application, making "dwell mode" 
useless and causing point-and-click mode to behave oddly; and secondly, 
clicking a mouse button causes a number of desktop features to change 
state, for instance StickyKeys resets on mouse click, menus may un-post, 
etc. etc.

If all you are doing is clicking on alphanumeric characters in a text 
field, things will "mostly work", but if you are using non-alphanumeric 
keys, keyboard shortcuts, or posting menus, things will start to act 
strange if you are using the "system core pointer" to interact with any 
onscreen keyboard on the X Windows system.

Bill

>
> - Henrik
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list at gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list