Re: the keyboard accessibility capplet

[Jody Goldberg <jody gnome org>]

On Wed, Sep 25, 2002 at 08:01:37PM -0400, Havoc Pennington wrote:
> > >  - the title of the window is inconsistent with other capplets 
> > >    ("Configuration" not "Preferences").
> > >  - putting a space before colons in labels is just wrong.
> > UI review missed them, changing is trivial.
> 
> All these changes are trivial if we can just go in and change them,
> but this particular capplet seems to be really hard to get changes
> into. ;-)
you had only to ask.
done in HEAD but not 2.0 because it does not rise to a level that
requires string freeze breakage.

> > >  - the button to open the Keyboard capplet is bogus;
> 
> To me this is a "we can't make a decision, let's just make it
> configurable!" kind of choice.
It seemed like a reasonable middle ground between replicating the
functionality and merging the keyboard capplets.  Those were both
tried and rejected after some testing.
 
> > >  - unless it was fixed recently, it still appears as the only item 
> > >    in its own submenu.
> 
> A one-item menu _looks really broken_. I couldn't ship Red Hat Linux
> 8.0 with that in there, and GNOME upstream shouldn't ship that way
> either.
Agreed, but consensus produced the current location.  Would anyone
object to moving it into Advanced ?
 
> As I said, I hate to keep bringing it up, but for whatever reason it's
> still broken... to me if I put all the other control panels next to
> this one, the accessibility capplet sticks out as very different.
> 
> Does no one else agree?

I suspect we all dislike it (lets avoid pejorative phrases like
'broken').  The problem is that given N people there are N+2
proposed solutions.  If we create the 'make Havoc happy keyboard
accessibility capplet' then I'll be thwaped from 3 sides by several
irate people.

- Mouse keys stay : They are a feature.
- Global enable/disable stays : This is useful if you're actually
  using the thing.  Not so much as a ui item but because a
  non-accessibility user (is there a more PC way to say that ?) can
  disable things by simply typing, and the accessibility user wants
  to be able to re-enable.  This mirror the XKB implementation.

- Slider spinner combo stays : it is useful to accessibility folk.
  This grew on me.  My preference would be to use this in the other
  capplets too.  However, it seems better to wait for the usability
  folk to weigh in on it.


Open to debate
- remove import AccessX CDE file : I'd prefer to see this in a
  migration wizard.  Given that we can't currently generate the file
  I don't see alot of repeat use for this.

- button to bring up the keyboard capplet (and the sibling in the
  keyboard capplet).  I don't see a better choice.  If we merge them
  the buttons go away, but we preclude the ability to have other
  accessibility features there.  Replicating the functionality seems
  really ugly.  What other choice is there ?

- Moving the capplet into Advanced.  I am not a fan of 1 entry
  menus.  Unless there is a concrete plan to have something else in
  there in the near future then this seems like a good idea.

Havoc the reality here is that neither of us are accessibility
users.  Therefore we should defer to the insights of people familiar
with that domain.  You say its broken and ugly.  I'm fed up after
months of random conflicting complaints.  This was reviewed and
accepted, and it should stay until something universally accepted as
better is written.