Re: Advice requested on deprecating AT-SPI/CORBA

[Willie Walker <William Walker Sun COM>]

> (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?

Will