Re: Proposal to enable accessibility by default for GNOME development releases

[Rodney Dawes <dobey novell com>]

On Mon, 2006-10-16 at 13:10 +0200, Alexander Larsson wrote:
> On Sun, 2006-10-15 at 20:32 -0400, Willie Walker wrote:
> > > I'd say that the best way to do this is like the code for G_DEBUG,
> > > just check gnome version in libgnomeui, and if odd number, enable it
> > > unconditionally. If even, check the gconf key.
> > 
> > Sounds good to me.  It seems like the right spot to do this might be in
> > gnome-session/main.c.  I submitted an enhancement request and potential
> > patch to gnome-session for this, though I've been unable to autogen
> > gnome-session in order to see if it works (let alone compiles):
> > 
> > http://bugzilla.gnome.org/show_bug.cgi?id=362457
> 
> I'm not sure about that. That makes it pretty hard to disable it, say if
> you want to test something without a11y.

I imagine this need to test without a11y is based on the idea that the
a11y framework will introduce new bugs which aren't necessarily in your
code, and would not otherwise be there. The goal with enabling a11y by
default is so that we can fix all of these bugs, and eventually just get
rid of the need for a gconf key and ugly hack that loads GTK+ modules to
enable a11y support, and have it Just Work (TM) all the time.

Note that this also is not to enable sticky keys/etc... but only to
enable the loading of the a11y GTK+ modules by default. Your question is
one we face now for the critical-warnings-are-fatal hack. How does one
test without forcing the app to crash on critical warnings? One must
muck with their environment, and unset the variables. You could also do
this for the a11y hack. Most all of the issues that keep a11y from being
enabled by default in the first place, would be fixed, were people to
enable it and try to use their machines with it enabled by default. It
merely lacks testing and use in several areas.

-- dobey