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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
