GNOME Bugzilla – Bug 641869
Injecting GTK_PATH in the session environment doesn't work
Last modified: 2011-02-11 22:23:11 UTC
The problem with this approach is that GTK_PATH is read by both gtk2 and gtk3, so one of them is bound to see incompatible modules. I would recommend that for GNOME 3, we should have just one a11y stack, and we should focus on making that work, instead of perpetuating a complicated and not really working mechanism to switch between stacks.
I am adding code to GTK+ to keep it from crashing if it sees incompatible modules. But that doesn't fix the fundamental problem.
Just to clarify, you've built at-spi2-atk without --enable-relocate, and you're seeing GTK_PATH modified? If you have a spec file that is installing atk-adaptor/atk-bridge.desktop, then you should remove it--it only gets installed if --enable-relocate is passed. Otherwise I don't see what would be modifying GTK_PATH. Regardless, the relocate code was intended as a temporary measure to allow AT-SPI-CORBA and AT-SPI-DBus to co-exist on a filesystem so that people could test AT-SPI-DBus without disrupting their system. There might not be any reason to keep it around anymore; we'll discuss it at the next #a11y meeting.
Just to complete Mike Gorse comment. As he said enable-relocate was added in order to test both in the same system, and we already talked about remove it. One of the main reasons to keep it is because distributions (downstream) are still using at-spi, and it is not clear when they will made the move, so it is required to keep a way to install "the other" for testing purposes. We all agree that the relocate thing just add complexity on this, and that should be not required the sooner the better. Finally, FWIW, right now at-spi is mostly on maintenance mode, just solving major bugs if required (due the downstream thing) but not adding new features (ie: support for AtkSocket/AtkPlug), so it is "almost" officially deprecated, and the current upstream effort is done on at-spi2 (although right now "upstream effort" is basically "Mike Gorse effort").
(In reply to comment #2) > Just to clarify, you've built at-spi2-atk without --enable-relocate, and you're > seeing GTK_PATH modified? If you have a spec file that is installing > atk-adaptor/atk-bridge.desktop, then you should remove it--it only gets > installed if --enable-relocate is passed. Otherwise I don't see what would be > modifying GTK_PATH. > > Regardless, the relocate code was intended as a temporary measure to allow > AT-SPI-CORBA and AT-SPI-DBus to co-exist on a filesystem so that people could > test AT-SPI-DBus without disrupting their system. There might not be any > reason to keep it around anymore; we'll discuss it at the next #a11y meeting. a) I don't know what kind of at-spi2-atk package exactly was installed on the problematic system. But it was an upgraded F14 system, so maybe an old a11y package stuck around (we used to turn on relocate at some point...) b) We build our at-spi2-atk package with --disable-relocate, and it does not include atk-adaptor/atk-bridge.desktop. So I think what we've seem might just have been transient rawhide/upgrade breakage.
I talked with Luke Yelavich and Steven Shaw, and they both seemed fine with --enable-relocate going away in AT-SPI2 / to think it made sense. I'll remove it along with the desktop file if no one objects at tomorrow's meeting.
I have removed support for --enable-relocate from AT-SPI2 along with the .desktop file that sets GTK_PATH. So far I have not removed the checks that disable AT-SPI2 or redirect pyatspi if the at-spi-corba gconf key is set, since I don't think that they do any harm and gconf not being present should be treated equivalently to the key being off. Marking the bug resolved, in any case.