Re: detailed review of GOK

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.


- Henrik

gnome-accessibility-list mailing list
gnome-accessibility-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]