Re: Are Bounce and Slow keys mutually exclusive ?

[Bill Haneman <bill haneman sun com>]

On Thu, 2002-10-03 at 18:48, earl johnson wrote:
> Jody,
> 
> The attached email provides the rational for why the first version of
> AccessX made SlowKeys and BonceKeys mutually exclusive (both Sun and
> DEC introduced X versions with this feature). The reason it was put in
> is BounceKeys users won't be able to use the system if SlowKeys is also
> on and its acceptance time is >0. 

I believe Earl means "acceptance time > t", where t is the "maximum
length of time the user can reliably keep the key pressed" without
tremors causing a bounce.  If t is smaller than that time for a user
with tremors, SlowKeys can be useful to such a user if the tremors are
causing spurious keypresses that are not "bounces".

BounceKeys and SlowKeys are both about rejecting "false positives" with
regard to key presses, but they serve different roles.

-Bill

>The original designers of the
> functionality in AccessX raised this point with us when AccessX was
> being designed, we agreed it was a problem and put in the exclusivity.
> I don't know why other platforms allow them to both be on given the
> above.
> 
> Earl
> 
> > Date: Thu, 3 Oct 2002 12:42:26 -0400
> > To: earl johnson <Earl Johnson sun com>
> > Cc: calum benson sun com, bill haneman sun com, desktop-devel-list gnome org
> > Subject: Are Bounce and Slow keys mutually exclusive ?
> > Mime-Version: 1.0
> > Content-Disposition: inline
> > User-Agent: Mutt/1.4i
> > From: Jody Goldberg <jody gnome org>
> > 
> > On Thu, Oct 03, 2002 at 09:00:40AM -0700, earl johnson wrote:
> > > Having radiobuttons designed so you have to add a third button that 
> > > says don't select either one of those other 2 buttons seems bogus to me. 
> > 
> > The initial design used stock checkboxes but put in place the
> > exclusion with to visible rationale for it.  Before talking about UI
> > can we please get a normative response on whther they actually are
> > mutually exclusive ?  XKB makes them distinct the sun AccessX
> > extension makes them conflict.  Which is correct ?
> ----
> 

> From: Earl Johnson <Earl Johnson sun com>
> To: bill haneman sun com
> Cc: alan coopersmith sun com, X-GNOME-Access sun com, gnome_bugs sun com, Earl Johnson sun com
> Subject: Re: BugId 4743379 : (P3/S3) New Bug Created, Please Evaluate
> Date: 09 Sep 2002 15:39:36 -0700
> 
> Hi Bill,
> 
> I checked other art and also found no mention of exclusivity (which CDE
> implements). Having said this, the reason CDE implements exclusivity is
> because Mark Novak, the designer from Trace Research who first
> implemented AccessPak (DOS version of AccessX) and was directly
> involved in AccessX's design, said exclusivity was required. Compaq's
> version of AccessX also implemented the exclusivity. The following
> hilites why: SlowKeys requires a key to be held down for a specific
> length of time before the system accepts the key press.  BounceKeys on
> the other hand only accepts the first keypress of the user and requires
> time off the key before it will accept a press on the same key again.
> What combining these 2 functions together means for a user who needs
> BounceKeys (i.e. the user has tremors) is that they will never be able
> to get the system to accept a keypress from them because they are
> physically unable to fulfill what SlowKeys requires of them.  Luckily,
> I don't believe the SlowKeys user will be effected if BounceKeys is
> also on.
> 
> This is why I believe the bug is appropriate. There is a workaround in
> case this bug can't be fixed in the first release of GNOME 2 - the
> BounceKeys user can set the acceptance delay of SlowKeys to 0 seconds
> 
> See the following for more discussion on BounceKeys and SlowKeys:
> 	http://docs.sun.com/?p=/doc/806-2901/6jc3a4m21&a=view#accessxapp-14258
> 
> ej
>  
> > 
> > Alan/all:
> > 
> > The XKB standard appears to allow both of these features to be on at
> > once.  The CDE GUI did not allow it but it does appear to be valid and
> > useful, since key debounce and key delay are separate operations:
> > 
> > BounceKeys suppresses multiple key presses within a time duration (i.e.
> > after an initial key press)
> > 
> > SlowKeys suppresses key 'contact' events of short duration.
> > 
> > In most cases it is true that SlowKeys would mask the effect of
> > BounceKeys (since both are timer-based), but some users may wish to
> > affect a longer delay for BounceKeys than SlowKeys, in which case both
> > controls would be needed.
> > 
> > Note that other 'prior art' in the area of GUIs for AccessX  (other than
> > the CDE version) as developed by Dan Linder and distributed for some
> > time by the UIUC Rehab Department includes both BounceKeys and SlowKeys
> > controls in the same GUI, without exclusivity.
> > 
> > So I do not believe that this is a regression in any meaningful sense of
> > the word.  Changing the GNOME AccessX GUI to make Bounce and Slow keys
> > mutually exclusive would result in a limitation for a (presumably small)
> > subset of users.
> > 
> > regards,
> > 
> > -Bill
> > 
> > 
> > On Sat, 2002-09-07 at 00:45, alan coopersmith sun com wrote:
> > >  Bug Id: 4743379
> > >  Product: gnome
> > >  Category: gnome
> > >  Subcategory: accessibility
> > >  Release summary: gnome2.0_beta2
> > >  Bug/Rfe/EOU: bug
> > >  State: dispatched
> > >  Development Status: 
> > >  Synopsis: keyboard a11y capplet allows both BounceKeys & SlowKeys to be on 
> at once
> > >  Keywords: 
> > >  Severity: 3
> > >  Severity Impact: Significant
> > >  Severity Functionality: Secondary
> > >  Priority: 3
> > >  Responsible Manager: leob ireland
> > >  Responsible Engineer: 
> > >  Description:
> > > The GNOME keyboard accessibility control panel allows turning on both the
> > > BounceKeys & SlowKeys features at the same time.  These features should 
> instead
> > > be grouped together and be mutually exclusive - the only valid states should 
> be:
> > > 	- both off
> > > 	- BounceKeys on, SlowKeys off
> > > 	- SlowKeys on, BounceKeys off
> > > 
> > > Having both on at the same time should not be a valid state.
> > >  Justification:
> > > Regression from CDE AccessX GUI 
> > >  Work around:
> > > Run the old motif AccessX GUI under GNOME to get the correct behaviour.
> > >  Suggested fix:
> > > 
> > >  State triggers:
> > > 	Accepted: no
> > > 	Evaluation complete: no
> > > 	Evaluation: 
> > > 
> > > 	Commit to fix in releases: 
> > > 	Fixed in releases: 
> > > 	Integrated in releases: 
> > > 	Verified in releases: 
> > > 	Closed because: 
> > > 	Incomplete because: 
> > >  Duplicate of: 
> > >  Introduced in Release: 
> > >  Root cause: 
> > >  Program management: 
> > >  Fix affects documentation: no
> > >  Exempt from dev rel: no
> > >  Fix affects L10N: 
> > >  Interest list: X-GNOME-Access sun com
> > >  Patch id: 
> > >  Comments:
> > > 
> > >  See also: 
> > >  Hooks:
> > > 	Hook 1(hook1): 
> > > 	Hook 2(hook2): 
> > > 	Hook 3(hook3): 
> > > 	Hook 4(hook4): 
> > > 	Hook 5(hook5): 
> > > 	Hook 6(hook6): 
> > >  History:
> > > 	Submitter:            alanc	Date: Sep  6 2002  5:45PM
> > > 	Dispatch Operator:    bugtraq	Date: Sep  6 2002  5:45PM
> > > 	Acceptor:             	Date: 
> > > 	Evaluator:            	Date: 
> > > 	Commit operator:      	Date: 
> > > 	Fix operator:         	Date: 
> > > 	Integrating operator: 	Date: 
> > > 	Verify operator:      	Date: 
> > > 	Closeout operator:    	Date: 
> > >  Called in by:
> > >     Customer:
> > > 	Company: Sun Microsystems
> > > 	Employee: Earl Johnson
> > > 	User Role: A
> > > 	User Type: I
> > > 	Release: gnome2.0_beta2
> > > 	Hardware version: generic
> > > 	O/S version (unbundled products): 5.9
> > > 	SO Number: 
> > > 	Sun Contact: earlj
> > > 	Contact Name: William Johnson
> > > 	Contact Mailaddr: earl johnson sun com
> > >  Escalation(s):
> > >  Public Summary:
> > > 
> > >  Old Name: 
> > >  Bug End:
> > > 
> --------------------------------------------------------------------------------
> > > 
> > 
> > 
> 
> 
> 
> ------------- End Forwarded Message -------------
> 
> 
> 
>