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

[Bill Haneman <Bill Haneman Sun COM>]

On Tue, 2006-07-25 at 17:57, Havoc Pennington wrote:
> ...

>  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.

There must be some disconnect here, I thought we were talking about the
code in gnome_program_init that reads the gconf key and loads the
modules appropriately.  
I am pretty sure I have misunderstood you, since your comments below
don't make any sense to me in the context that I took them.  I will have
a closer look at the metacity code to see if I understand the changes. 

I agree with your summary points 100%.

Bill

> 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
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel