Re: Enable accessibility by default in development releases?

[David Malcolm <dmalcolm redhat com>]

On Fri, 2005-11-11 at 20:23 +0100, Claudio Saavedra wrote:
> On Fri, 2005-11-11 at 12:00 -0700, Elijah Newren wrote:
> [...]
> > FWIW, it effectively disables the reduced resources mode in metacity
> > (except that the minimization animation remains off) which would
> > result in part of Metacity being untested.  It may also drive users
> > mad from the constant slow keys and sticky keys dialogs that appear. 
> > (I know it shouldn't seem like common operations to press shift 5
> > times in a row or hold it down for over 8 seconds but I seem to
> > periodically do one or the other without thinking about it,
> > particularly the latter fairly often)
> 
> Considering that there are pros and cons, why force all developers,
> contributors and testers to take part in this? It would be good for the
> debugging of a specific part of the desktop, sure, but at a cost that
> probably not everyone wants to pay.

The opt-out is to run:
gconftool-2 --set --type bool /desktop/gnome/interface/accessibility false

> 
> Just like with the suggestion that Vicent made a few days ago regarding
> making GNOME crash. Instead of making this changes a *must* for all the
> people involved with the HEAD code, why not better making more noise
> (mailing lists, p.g.o, etc.) so everyone know that exists some areas of
> the desktop development that need some love?

Yes, I thought about this after I sent my original post.  Both things
potentially stop you dead when working on another feature.  

But I think there's a distinction, turning warnings into errors can kill
you for trivial reasons.  This proposal instead exercises more of
existing the code.  And, in theory (yeah, I know....), the a11y code
works, and we care about it (it's a big feature of GNOME); I'm already
running all of my own desktop machines with this setting (manually)
enabled and have been for months.

What I'm concerned about is that this stuff will get broken during
development of other features within the desktop and within
applications.  If only a small subset of people are running with these
features during 2.13, we might only discover the breakage until 2.14
when someone tries a11y in an app that didn't get any love (or too much
of the wrong kind of love)

Dave