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

[Bill Haneman <Bill Haneman Sun COM>]

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