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

[Bill Haneman <Bill Haneman Sun COM>]

On Tue, 2006-06-27 at 16:03, Chris Jones wrote:
> "The very same thing" refers to where you say that disabled users will
> complain if the onscreen keyboard conflicts with sticky keys.
> 
> What I am trying to say is that an onscreen keyboard should work
> whether sticky keys is on or not.

By its very nature, an onscreen keyboard (which will be emulating
physical keypresses) will interact with the physical keyboard driver and
settings.  This means that interoperability with things like XKB is just
a requirement of the task at hand.

> Surely an application changing system wide settings just so it can
> run, is an accessibility violation as the user might rely on
> non-sticky behaviour on the physical keyboard.  In other words one
> input device should not change the behaviour of all the others.

I have suggested several alternatives.  It is folly to create an
onscreen keyboard which emulates physical keypresses and then pretend
that it is independent of the physical keyboard - it's just not
realistic, since you'll be using Xtest "Fake" API to fake key presses
anyway.

> You keep referring to xkblib.  To get this to work I would have to
> change the x config to have an extra keyboard device.

That is not true!

>   The XTest api I
> am currently using does not allow me to specify which keyboard device
> I am emulating either.  I have difficulty seeing how I could use this.

Have you read the document section which I recommended to you?

It allows you to programmatically change the latch state of specific
modifiers, WITHOUT simulating a "press-and-hold".  It allows you to do
this in a way that does not change the way the physical keyboard works,
and doesn't trigger any warning dialogs.  XKB is available by default on
the XOrg server, so you shouldn't need to change your X configuration at
all.

> I understand the need for the dialogs.  If the system-wide settings
> are changing then I agree a dialog is needed.  This is yet another
> reason why I do not want to change the system wide settings.

The dialog does not post anytime the system-wide settings change - it
only posts in response to a change which it believes comes from the
SlowKeys or StickyKeys keyboard gesture.

As long as your keyboard latches keys by simulating a key press and then
simulating a release at a later time in the future, you will collide
with this dialog, because you are invoking the SlowKeys gesture. 
Period.  If you don't like that you can turn off the keyboard shortcuts,
i.e. make it so that holding the shift key down doesn't turn on
SlowKeys; however you should not make that the default for new users.

> I can see why GOK behaves as it does.  My opinion though is that it is
> not acceptable, another method must be found to solve the issue.

We'll be able to help you better if you are a little more open to our
suggestions.

Bill

> Bill Haneman said:
> 
> >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.
> 
> I find this difficult to understand, surely pop up menus are a pointer
> operation to begin with, and that it is possible to emulate this with
> a physical keyboard.  I fail to see the point of emulating this
> emulation with a pointer.  Except if one was using a pointer to
> emulate a scanning device.  Perhaps it would make more sense to
> disconnect the core pointer when GOK enters it's scanning mode?
> 
> Maybe it is just impossible to design a one-size fits all onscreen
> keyboard.  As evidenced by GOK, the result is a keyboard that is
> accessible to everyone but usable by no-one.
> 
> 
> On 27/06/06, Bill Haneman <Bill Haneman sun com> wrote:
> > On Tue, 2006-06-27 at 01:42, Peter Korn wrote:
> > > Hi Chris,
> > >
> > > One more thing.  You write:
> > >
> > > > 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.
> > >
> > > Have you filed an RFE on this issue (seeking a way to invoke the
> > > system-wide Sticky-Keys functionality programatically without the user
> > > dialog box),
> >
> > This is trivial to do.  If you modify the key via gconf API, either by
> > linking to gconf or just spawning a gconftool-2 command line, then you
> > can change these settings without triggering the warning dialogs.  If
> > this has somehow regressed (it has worked on every system I know of, for
> > several years), then a bug needs to be filed.
> >
> > Billy
> >
> > > or are you simply trying to "work around it"?  I would hope
> > > that part of a SoC project is to at least file bugs/RFEs for things you
> > > want, even if you "work around them" for the purposes of meeting a
> > > project deadline.  I would hope that filing bugs/RFEs is part of the
> > > purview of SoC projects.
> > >
> > > Regards,
> > >
> > >
> > > Peter Korn
> > > Accessibility Architect,
> > > Sun Microsystems, Inc.
> > >
> > > > Hi Chris,
> > > >
> > > > I think there are two issues here.  Well, three:
> > > >
> > > >  1. Can an on-screen keyboard implement "sticky" modifiers without using
> > > > the system support for sticky modifiers?
> > > >  2. Can an on-screen keyboard circumvent/disable the system support for
> > > > sticky modifiers (and slow keys, and...)?
> > > >  3. Is the right way to "fix" what is "broken" in GOK doing another
> > > > project rather than working with the existing GOK code to "fix" those
> > > > "broken" things?
> > > >
> > > > I suggest that #3 may be somewhat religious at this point; I'm
> > > > personally saddened that we aren't at least looking seriously at GOK
> > > > improvements, but fundamentally a goal of UNIX accessibility is to
> > > > foster the development of a rich accessibility ecosystem - and a rich
> > > > ecosystem has room for multiple approaches to similar problems (cf. Orca
> > > > and Gnopernicus and LSR).
> > > >
> > > > I have no issues with #1 - I see no reason why an on-screen keyboard
> > > > cannot have its own way of making certain modifiers sticky on its own
> > > > user interface *without* doing so through the system-wide setting
> > > > mechanisms.  Such a decision is I think a valid user-interface policy
> > > > decision of an individual application.
> > > >
> > > > However, it is a direct Section 508 violation for an application to
> > > > override or ignore system-wide accessibility settings.  It is even more
> > > > egregious for an application that claims to be at least in part for
> > > > people with disabilities (and thus an 'enlightened' application) to do so.
> > > >
> > > >
> > > > So, my suggestion is that if you simply cannot possible use the
> > > > system-settings for sticky keys as part of your own UI, that you make
> > > > things sticky your own way; however that if the system-wide settings are
> > > > on that you use and respect those (complete with the dialog box that you
> > > > seem to dislike).
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Peter Korn
> > > > Accessibility Architect,
> > > > Sun Microsystems, Inc.
> > > >
> > > >
> > > >> 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.
> > > >>
> > > >> 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 slow keys dialogue however is another matter though.  Normal
> > > >> operations are not resumed until it is dismissed.  Which in itself
> > > >> incredibly annoying.
> > > >>
> > > >> 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.
> > > >>
> > > >> 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.
> > > >>
> > > >> 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
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >
> > > > _______________________________________________
> > > > 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
> >
> >
> 
> 
> -- 
> 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