Hi Bill, Henrik... I have minor comments:
Quoting Bill Haneman <[EMAIL PROTECTED]>: > 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 > > [email protected] > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > > > _______________________________________________ > gnome-accessibility-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > -- Ubuntu-accessibility mailing list [email protected] http://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
