Re: detailed review of GOK
- From: david bolter utoronto ca
- To: Bill Haneman <Bill Haneman Sun COM>
- Cc: ubuntu-accessibility lists ubuntu com, gnome-accessibility-list gnome org
- Subject: Re: detailed review of GOK
- Date: Mon, 12 Dec 2005 09:46:16 -0500
Hi Bill, Henrik...
I have minor comments:
Quoting Bill Haneman <Bill Haneman 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 gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]