Advice requested on deprecating AT-SPI/CORBA

[Willie Walker]

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@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Alberto Ruiz-4]

2009/10/21 Willie Walker <William.Walker@...>:

> 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".

Can we force them to not hardcode it and yet preserve atk-bridge so
that we can change it in the future if needed? a pkg-config variable
would solve this I'd say.

--
Un saludo,
Alberto Ruiz
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Willie Walker]

>> 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".
>
> Can we force them to not hardcode it and yet preserve atk-bridge so
> that we can change it in the future if needed? a pkg-config variable
> would solve this I'd say.

We can certainly ask them to change.  The problem is that the Firefox
and OOo release schedules are completely de-coupled from GNOME's.  As a
result, by requiring them to change for AT-SPI/D-Bus to succeed, we have
introduced another dependency that is another point of failure and delay.

Will


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Alberto Ruiz-4]

2009/10/21 Willie Walker <William.Walker@...>:

>>> 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".
>>
>> Can we force them to not hardcode it and yet preserve atk-bridge so
>> that we can change it in the future if needed? a pkg-config variable
>> would solve this I'd say.
>
> We can certainly ask them to change.  The problem is that the Firefox and
> OOo release schedules are completely de-coupled from GNOME's.  As a result,
> by requiring them to change for AT-SPI/D-Bus to succeed, we have introduced
> another dependency that is another point of failure and delay.

What about keeping in mind to ask them until we've got rid of the
CORBA world? It kind of would be unfortunate to stumble into a similar
issue in the future if we needed to change the module name for some
reason :-)

> Will
>
>
>



--
Un saludo,
Alberto Ruiz
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Willie Walker]

Alberto Ruiz wrote:

> 2009/10/21 Willie Walker <William.Walker@...>:
>>>> 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".
>>> Can we force them to not hardcode it and yet preserve atk-bridge so
>>> that we can change it in the future if needed? a pkg-config variable
>>> would solve this I'd say.
>> We can certainly ask them to change.  The problem is that the Firefox and
>> OOo release schedules are completely de-coupled from GNOME's.  As a result,
>> by requiring them to change for AT-SPI/D-Bus to succeed, we have introduced
>> another dependency that is another point of failure and delay.
>
> What about keeping in mind to ask them until we've got rid of the
> CORBA world? It kind of would be unfortunate to stumble into a similar
> issue in the future if we needed to change the module name for some
> reason :-)

You bet - I can file some bugs with FF and OOo (and gdm if it also still
hardcodes the string).  In the meantime, I think we need to stick with
the simplifying assumption that they will not change prior to the GNOME
2.30 release, so we need to work with that constraint.

Will

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Alberto Ruiz-4]

2009/10/21 Willie Walker <William.Walker@...>:

> Alberto Ruiz wrote:
>>
>> 2009/10/21 Willie Walker <William.Walker@...>:
>>>>>
>>>>> 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".
>>>>
>>>> Can we force them to not hardcode it and yet preserve atk-bridge so
>>>> that we can change it in the future if needed? a pkg-config variable
>>>> would solve this I'd say.
>>>
>>> We can certainly ask them to change.  The problem is that the Firefox and
>>> OOo release schedules are completely de-coupled from GNOME's.  As a
>>> result,
>>> by requiring them to change for AT-SPI/D-Bus to succeed, we have
>>> introduced
>>> another dependency that is another point of failure and delay.
>>
>> What about keeping in mind to ask them until we've got rid of the
>> CORBA world? It kind of would be unfortunate to stumble into a similar
>> issue in the future if we needed to change the module name for some
>> reason :-)
>
> You bet - I can file some bugs with FF and OOo (and gdm if it also still
> hardcodes the string).  In the meantime, I think we need to stick with the
> simplifying assumption that they will not change prior to the GNOME 2.30
> release, so we need to work with that constraint.

We're on the same boat now then :-)

>
> Will
>
>



--
Un saludo,
Alberto Ruiz
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Vincent Untz]

Hey,

Le mercredi 21 octobre 2009, à 12:57 -0400, Willie Walker a écrit :
> 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. ;-)

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

> Not launching both registryd's at once
> --------------------------------------

[...]

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

> pyatspi
> -------

[...]

> 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...

Vincent

--
Les gens heureux ne sont pas pressés.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Willie Walker]

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

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Vincent Untz]

Le mercredi 02 décembre 2009, à 09:57 -0500, Willie Walker a écrit :

> >>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.

Cool!

[... moving to python stuff...]

> 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.

Good to know! Although, hrm, wouldn't gnome-mag and gok still need it?
(sorry if you have to explain to me the same thing again and again :/)

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

Hrm, what about first checking if we're running in a X session? This is
still a hack, but it at least removes the gconftool-2 call in many cases
where we wouldn't want this to happen.

Something like:

import commands, os, sys; os.environ.has_key('DISPLAY') and (commands.getoutput('gconftool-2 --get /desktop/gnome/interface/at-spi-corba') == 'true') and sys.path.insert(0, '@prefix@/lib/python@PYTHON_VERSION@/site-packages/pyatspi-corba')

I'm sure some python heroes could find a non-hacky solution ;-)

Vincent

--
Les gens heureux ne sont pas pressés.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list