Re: Advice requested on deprecating AT-SPI/CORBA

(Hrm, I'm obviously late ;-))


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.

Does this mean that the registryd will start and stay if the value of
at-spi-corba is true, but the value of accessibility is false?

No - the /desktop/gnome/interface/accessibility should still be the gating factor. /desktop/gnome/interface/at-spi-corba will be used just to decide which one should be used if /desktop/gnome/interface/accessibility is True.

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.

I see that this is implemented with a gconftool-2 call in
pyatspi-corba.pth. As you point out, this is a big hack :-) My main
worry here is that every time python is started, this is called. It's
probably not that much of an issue if this is happening from within a
GNOME session, but I wouldn't want scripts run by sysadmins to have
this, for example.

I can't think of a much better hack right now, but this is probobably
something we should investigate...

Yep - it's a big hack. The idea is that it should be an interim solution for the GNOME 2.29.x series only. The goal is that by GNOME 2.30, we can dump the CORBA solution completely.

I tried monkeying around with ways to isolate this to just a pyatspi solution. The idea I was chasing would be that the CORBA solution would be installed under pyatspi-corba and the D-Bus solution would be installed under pyatspi-dbus. There would be some sort of 'pyatspi' shim module that would effectively do a "import pyatspi-dbus as pyatspi" or "import pyatspi-corba as pyatspi" based upon the gconf setting. My Python chops weren't strong enough to figure that out. Any thoughts on this?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]