From: Mike Gorse <[email protected]> > So we had pyatspi2 importing gconf, using GConf from gi.repository > (the new pygi-based binding) if available, to check whether the > at-spi-corba key is enabled. (If it could not find a GI typelib for > gconf, then it would fall back to trying the old pygtk-based binding. > If pyatspi2 was built with --enable-relocate, then all of this code > would not be invoked. So this is why some people have been seeing the > traceback and some haven't.) > > Anyway, I just pushed a change to pyatspi2 to make it call gconftool-2 > rather than trying to import gconf. This fixes the issue for me, > although it might add 10-20 ms to the startup time, so feel free to > test.
Yes I have tested it and it works for me. Thanks. Just one question, that means that now pyatpi2 has a dependency with gconftool-2? > I'm not sure if we should even still be using a gconf key for this. > We may want to migrate the key to gsettings. The only downside that I > see to this is that it leaves open the question of what to do if > at-spi-corba is built with --disable-relocate. My inclination would > be to leave things as they are in that case, continuing to let > at-spi-corba use a gconf key, since AT-SPI-CORBA being the default > would correlate with a GNOME 2 setup, but this would mean that the > behavior in the two cases is no longer parallel. Well, just one question. Will the relocate support there always? I thought that it was added as a provisional solution, in order to help at-spi2 migration. As most of the distros are still not distributing at-spi2, and in the same way just a "middle term gnome3", I guess that at-spi2 would be only used on a pure "GNOME 3.0" stack. So one drastic option would be remove that support in the future, avoiding asking for old gconf properties. BR === API ([email protected]) _______________________________________________ gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
