The story so far: in Accessibility warnings I talked about those irritating “Couldn’t register with accessibility bus” warnings on SL7, and how suppress them (you define an environmental variable NO_AT_BRIDGE to 1.)
I’ve since learned that although this workaround works perfectly well on most of the window managers we offer, it rather mysteriously doesn’t work if you happen to use GNOME or GNOME Classic. The lucky users of these window managers still see the warning messages, while the users of (for instance) MATE or KDE Plasma Workspace are left to get on with their lives in blissful peace don’t.
At first I thought that this might be a quirk of our rather old bash default environment infrastructure, but extensive experimentation established that that wasn’t the case. Our bash startup files are quite capable of defining, for instance, NO_BT_BRIDGE; it’s just NO_AT_BRIDGE which isn’t present in the environment, and only if you use GNOME or GNOME Classic. And it doesn’t matter what value it’s given.
After a lot of searching of GNOME related documentation and sources and blogs and mailing lists I eventually found gnome-shell, and in particular its source, which contains this:
/* Prevent meta_init() from causing gtk to load gail and at-bridge */
g_setenv ("NO_AT_BRIDGE", "1", TRUE);
meta_init ();
g_unsetenv ("NO_AT_BRIDGE");
It unsets NO_AT_BRIDGE. Whether or not it was set before. Without checking its value.
Thanks, guys.
Oh well. However frustrating this might initially have been, it was at least nice to get a rational explanation, and to know that I wasn’t imagining it, or coping with a haunted shell environment.
Also, to be fair, NO_AT_BRIDGE is an undocumented (though widely swapped on support sites) workaround. As such, GNOME can do with it what it likes.
At this point I could have patched the gnome-shell source to make it restore the previous value of NO_AT_BRIDGE rather than unsetting it in a blanket fashion; but this would have opened up a Pandora’s Box of tracking future versions of the package, remembering to patch them in the same way, and no doubt eventually forgetting the reason why this patching was being done. All to get rid of some irritating but ultimately quite unimportant warning messages. I decided merely to document the quirk, and give the remaining affected users a workaround, at: