Re: [g-a-devel] Slow keys dialog

[Bill Haneman <Bill Haneman Sun COM>]

Hi Chris:

I'll try to respond to each of your points in turn:

On Tue, 2006-06-27 at 00:51, Chris Jones wrote:
> But this very same thing makes it very awkward who want sticky keys on
> the keyboard and non-sticky on a physical.  Which would be true for
> all non-a11y users and some a11y users.

I don't understand what you are saying here, "the very same thing."  My
suggestion to use XKB client API would make it quite feasible for the
physical keyboard to be non-sticky and for the onscreen keyboard to be
sticky.  Please re-read my post and check the XKB APIs.  If after
investigating it you still can't find what you are looking for, email me
and I will try to assist - but you should read section 10.6 of the
XKBlib manual first.

> In the end though the only manner it interferes with my keyboard is
> the annoying dialogue that pops up, and the average  gnome-ally user
> will probably be plenty used to seeing annoying dialogs anyway.

The dialog pops up because you are indeed turning on SlowKeys.  This is
because of the way in which you are implementing sticky-keys in your
application.  What you should avoid is generating a key-press without a
following key-release, since this triggers SlowKeys just as it does when
you press and hold the Shift key on the physical keyboard.  

Perhaps you are talking about some other dialog as well?  I'm afraid
it's not clear from your messages.

> The slow keys dialogue however is another matter though.  Normal
> operations are not resumed until it is dismissed.  Which in itself
> incredibly annoying.

Without it, the keyboard would silently begin to require long press and
hold sequences in order to work; this is necessary for users with some
types of disabilities, but it's essential that the end user be warned
when the keyboard's behavior is being changed in this way (in response
to end user action, which is the case here).

> When planning the SOK I wanted to stay away from the three odd dialogs
> that GOK pops up when it is started.  The plain fact is I don't want
> any dialogs when starting SOK.  At all.

You can make GOK suppress those warnings I believe.  If you do get them,
READ THEM, they are telling you that your system has serious
configuration issues which may make GOK unusable!

> Using the system wide sticky keys means I need to have at least one
> dialog box when my keyboard starts and is therefore completely
> unacceptable.

This isn't at all true.  You can easily programmatically turn this
feature on when your keyboard starts, and turn it off when it exits -
you can even turn the feature on and off when the mouse enters and
leaves your keyboard, if that's what you want.

Bear in mind that ANY onscreen keyboard that uses the mouse will fail to
work properly when used to pop up menus, etc. via keyboard navigation,
because of system toolkit pointer grabs.  Are you aware of that fact? 
It will strike your onscreen keyboard as well.  This is the reason for
GOK's somewhat brittle configuration requirements, and the reason you
are warned not to use GOK via the system core pointer.

Bill

> On 26/06/06, Bill Haneman <Bill Haneman sun com> wrote:
> > On Mon, 2006-06-26 at 22:28, Henrik Nilsen Omma wrote
> > > Chris Jones wrote:
> > > > ...
> > > >
> > > > In other words I cannot spend the summer making gnome-a11y suitable
> > > > for my needs.  What I need is a temporary work around until after the
> > > > SoC when I could find time to work on this aspect of gnome-a11y and
> > > > fix my program so it is not an "accessibility violation".
> > > Chris,
> > >
> > > Can you not simply make SOK remember that shift was pressed and keep the
> > > state internally in SOK? IOW:
> >
> > We tried this with GOK at an early stage and it was not satisfactory.
> > It also clashed badly with StickyKeys.  It doesn't make sense to build
> > an onscreen keyboard and then not expect disabled users to try and use
> > it, and they will rightly complain if it conflicts with StickyKeys.
> >
> > If you really are unwilling to turn on the global StickyKeys gconf key
> > while the onscreen keyboard is posted, or at least when the pointer is
> > inside it... (and I really do not understand why this would be a
> > problem) there is XKB ABI which you can use to change the latch/lock
> > status of individual modifier keys.  This should do exactly what you
> > want without making StickyKeys active for the physical keyboard.
> >
> > google for XKBlib.pdf to find the XKB client manual, I believe it's
> > section 10.6 that has the relevant client APIs.
> >
> > regards
> >
> > Bill
> >
> > > 1. when the user clicks shift you set a flag. When a letter is clicked
> > > SOK sends shift+<letter>+unshift to X and removes the flag.
> > >
> > > 2. When shift is clicked twice you set a sticky flag. Again, each time
> > > the user clicks a letter, SOK sends shift+<letter>+unshift. When shift
> > > is clicked again you unset the flag.
> > >
> > > That way you avoid triggering slow keys and avoid making an
> > > 'accessibility violation'.
> > >
> > > Bill, is it an accessibility violation to have unusable accessibility tools?
> > >
> > > - Henrik
> > >
> > > _______________________________________________
> > > gnome-accessibility-list mailing list
> > > gnome-accessibility-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
> >
> >
> 
> 
> -- 
> Chris Jones
> 
> jabber - skating tortoise gmail com
> msn - skating_tortoise dsl pipex com
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list