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 > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
