Bill Haneman wrote:
> Looks to me as though this has caused a major regression, if I
> understand correctly.
>
> Back in the ancient days when the AT support was initially being added,
> we were discouraged from relying on environment variables to control the
> loading of accessibility modules. The gconf and gnome_program_init
> stuff was written to address this "problem". Why has the recommended
> solution suddenly become an 'ugly hack' ?
I have been very consistent on this (as documented in that metacity
bug), and I know Owen was also saying the same thing.
The reason this is an "ugly hack" is that it involves cut-and-pasting
the same sizable boilerplate code into lots of apps, when it obviously
could be fixed generically. It's just that people were too lazy to fix
it generically, and instead went on a cut-and-paste spree. That the
cut-and-paste spree included libgnome and thus got some subset of apps
all at once hardly changes the basic situation.
Nobody should really need to be told this is an unacceptable patch, but
in any case people were told.
I accepted it _anyway_ as emergency band-aid, but then the people doing
the patch abused that lapse of judgment and did not go back and remove
the band-aid and fix things properly despite being explicitly asked to
do so and being given a multi-year grace period.
Which is why "no band-aids" is usually a good policy on the part of
maintainers.
> The GTK_MODULES solution has some nasty issues - some theoretical, some
> real - for instance it tends to break gtk-1.2 stuff badly. It also
> means that we have to load gnome-specific code into gtk-only programs if
> we don't use gnome_program_init, since there's no way to tell whether
> libgail-gnome needs to be loaded or not; we just have to add it to the
> GTK_MODULES list. (If nothing else, we need to make this change in
> gnome-session, in order to reverse the regression).
Read the bugs involved here; GTK_MODULES is not involved, it's an
xsetting with a module list, which GTK 1.2 will ignore.
Loading libgail-gnome in gnome_program_init is fine, since only GNOME
programs need it. The gtk module list on the display could presumably
only include things that all gtk apps should load.
> A better solution would be to use an XSETTING for a11y instead of just a
> gconf key, so that apps could detect it w/o a gconf dependency.
This is not related to the module loading fix. Having
gnome-settings-daemon set an XSETTING based on the existing a11y gconf
key would be our normal approach to this, and allow non-gconf apps to
check the "a11y enabled" flag.
The problem is not checking this flag in metacity though, it's having
all the cut-and-paste code.
The point of the metacity revert is that the same module loading / a11y
setup code should not be in every single app, if every gtk app should do
it, then get gtk to do it somehow, someway. Anything that involves
cut-and-pasting all over every app is a broken hack.
If there's a11y code in an app that is truly specific to that app, then
that is NOT a hack and is just fine. And it's fine for apps to look at
the global a11y setting in order to decide whether to run that code.
In summary:
- if every libgtk app should do something, get that code in gtk
- if every libgnome-using app should do something, get that code in
libgnome
- if only a particular app should do something, get that code in that
app
Havoc
_______________________________________________
Gnome-accessibility-devel mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
