Re: [g-a-devel] Problems with Orca and Accerciser calling GConf client and at-spi2

[Piñeiro <apinheiro igalia com>]

From: Mike Gorse <mgorse alum wpi edu>

> 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 (apinheiro igalia com)