Hi All:
We're slated to have the AT-SPI/D-Bus stuff in place for 2.29.2. Things
are chugging away and looking positive. I have some questions about
some approaches we are going to take and would like some opinions and
advice for how to do it better if your stomach is weakened by the
proposed approaches. In other words, speak up now before it's too late. ;-)
One of the goals is to try to keep the AT-SPI/CORBA stuff around for a
bit so as to let people who depend up AT-SPI for other things to have
some stability. The current path is that people would get AT-SPI/D-Bus
with GNOME 2.29.2 by default, but we'd have an option for people to
choose AT-SPI/CORBA if they want/need it.
For the most part, we can set things up so there is very little overlap
between AT-SPI/CORBA and AT-SPI/D-Bus on the file system. The two main
overlaps that we are facing are the atk-bridge GTK+ module and the
pyatspi module. We also need to deal with *not* always launching the
AT-SPI/CORBA at-spi-registryd deamon when we know the AT-SPI/D-Bus stuff
will be used -- launching the CORBA and D-Bus based registryd's
simultaneously can cause the desktop to hang.
Not launching both registryd's at once
--------------------------------------
The AT-SPI/D-Bus registryd starts/restarts via D-Bus activation, so
there's no need for it to have a *.desktop file and it will only launch
if someone tickles it (e.g., via the D-Bus based atk-bridge or pyatspi
module). The AT-SPI/CORBA registryd, however, currently starts with an
autostart *.desktop file,
/etc/xdg/autostart/at-spi-registryd.desktop, that is keyed off the GNOME
a11y gconf key, /desktop/gnome/interface/accessibility.
As a potential solution, we can modify the AT-SPI/CORBA *.desktop file
to key off of a new gconf key, /desktop/gnome/interface/at-spi-corba.
The existing /desktop/gnome/interface/accessibility key will be used
everywhere else as normal, but this new key will be used to specify
whether the old or new infrastructure should be used.
atk-bridge
-----------
Due to others hardcoding the string "atk-bridge" in their code (e.g.,
Firefox and OOo), the GTK+ a11y module has to be named "atk-bridge". We
could ask Firefox and OOo to not hardcode the name, but we'd end up in a
versioning hell with external apps not tied to the GNOME release
schedule. So, I'd like to make the simplifying assumption that they
will not change and we need to deal with "atk-bridge".
As a possible solution, we can modify AT-SPI/CORBA 2.29.2 to install its
atk-bridge module somewhere else (e.g.,
/usr/lib/gtk-2.0/modules/at-spi-corba/libatk-bridge.so). We would then
modify the AT-SPI/CORBA registryd to modify gnome-session's GTK_PATH to
find the CORBA-based GTK+ module first.
pyatspi
-------
The "pyatspi" module is used by many Python source modules, such as
Orca, accerciser, and LDTPv2. The AT-SPI/D-Bus "pyatspi" module is also
designed to be a drop in replacement for the AT-SPI/CORBA "pyatspi"
module. As a result, a name change would be both unnecessary and
cumbersome.
As a possible solution, we can modify AT-SPI/CORBA 2.29.2 to install its
pyatspi module under site-packages/pyatspi-corba/pyatspi and put a
site-packages/pyatspi-corba.pth file in place. The pyatspi-corba.pth
file would prepend Python's sys.path with site-packages/pyatspi-corba if
a new gconf key, /desktop/gnome/interface/at-spi-corba (the same one
described above), was True. This is admittedly a big hack, but the
thinking is that we really only want this scaffolding in place until we
finally pull the plug in AT-SPI/CORBA.
Thoughts?
Will
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
