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



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]