detailed review of GOK

[david.bolter at utoronto.ca]

Hi Bill, Henrik... 

I have minor comments:

Quoting Bill Haneman <Bill.Haneman at Sun.COM>:

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

It makes sense to me too, but we don't count Bill ;-)  We're too deep inside.

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

I confirm the problems faced with using the system core pointer. Overcoming the
problems has caused a great deal of developer pain. Henrik, if you and ubuntu
could help improve the gok feedback (dialog) -- to make it less confusing that
would be very welcome. 

cheers,

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