Re: [g-a-devel] GnomeClient replacement?
- From: Havoc Pennington <hp redhat com>
- To: Bill Haneman <Bill Haneman Sun COM>
- Cc: gnome-accessibility-devel gnome org, desktop-devel-list gnome org, Elijah Newren <newren gmail com>
- Subject: Re: [g-a-devel] GnomeClient replacement?
- Date: Tue, 25 Jul 2006 12:57:47 -0400
Bill Haneman wrote:
Looks to me as though this has caused a major regression, if I
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
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.
- if every libgtk app should do something, get that code in gtk
- if every libgnome-using app should do something, get that code in
- if only a particular app should do something, get that code in that
] [Thread Prev