Re: [g-a-devel] GnomeClient replacement?

[Havoc Pennington <hp redhat com>]

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