Re: that darned accessibility capplet



On Fri, 2002-09-27 at 15:22, Jody Goldberg wrote:
> On Fri, Sep 27, 2002 at 03:06:00PM +0100, Bill Haneman wrote:
> > Earl Johnson said:
> > > 
> > > This is re-run feedback from me but I think the capplet should be a
> > > tabbed pane with 2 tabs - one tab for StickyKeys, MouseKeys, and
> > > ToggleKeys; the other a keyboard response tab containing RepeatKeys,
> > > BounceKeys, and SlowKeys.
> 
> Remember that 'RepeatKeys' is _not_ part of gnome accessX.  That is
> handled by the keyboard capplet.

That's a change from AccessX, (and a difference from Access* stuff,
including XP accessibility dialogs).  All those *do* consider key repeat
an important part of keyboard accessibility.

The change was not uncontroversial.  I think that if we do rearrange the
accessibility capplet, we should be willing to re-think that issue as
well.  To be honest, the existing "Keyboard" capplet is a little weird,
since it includes cursor blink rate, and sounds.  (Does no-one else find
that weird?)

Why not move sounds to the "sound" capplet, blink rate to
"Accessibility" or "Theme", and put key repeat in "Accessibility"?  

To make sure "ordinary" users (as opposed to our "extraordinary" users
;-) could find the control, we could include a button-link to
Accessibility-keyrepeat from some other capplet, rather than vice-versa
as we now do.

> Having such a split would definitely go a long way towards easing
> the massive crowding.

yes - but where would we put the "General" checkboxes? In a third,
"General" tab?

> > > 	Window's added an additional feature along these lines that
> > > 	AccessX never had - it posts a popup the first time any feature
> > > 	is invoked from the keyboard and asks the user then if they
> > > 	want to fully disable keyboard accessibility. This would be a
> > > 	good thing to see added to the GNOME desktop.
> > 
> > Yeah, that does sound cool, and it will help prevent weird but reports
> > ;-)
> 
> Do we need to differentiate between another app enabling things,
> and the magic keystrokes ?  Its easy to catch the change (we already
> do).  However, there is no clear cut way to know what caused it.  Eg
> even when the settings-daemon changes things the X server notifies
> it that the state changed.

Hmm, I think we would need to differentiate.  Perhaps we could detect
whether the accessx capplet was active or not, and only use the popup if
the capplet was not onscreen.

-Bill




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]