Re: Considering remaining with CORBA accessibility framework for Ubuntu 10.04, Lucid Lynx.

[Willie Walker <William Walker Sun COM>]

Hi Luke:

Being safe and stable is a good thing.  We recently worked on some 
solutions to allow the CORBA and D-Bus solutions to co-exist on the file 
system and then allow for the setting of a key to switch between the two 
(you cannot run both at the same time).  With this, you should be able 
to ship both.

The current default solution we hope to achieve for GNOME 2.29.2 is that 
AT-SPI/D-Bus will be the default, but you can switch to AT-SPI/CORBA by 
setting a boolean gconf key.  All the code is in place in the CORBA and 
D-Bus solutions to do this and we're waiting to fix a few more issues in 
the D-Bus solution before pulling the trigger.

Support for doing the opposite (i.e., making the CORBA solution the 
default and providing a gconf key to switch to the D-Bus solution) is 
marginally there in the builds for both, but it needs more testing and 
probably some modification.

You can also read more about the shift from CORBA to D-Bus at the 
following URLs (damn me for screwing up the creation of the second WIKI 
page - I didn't notice that I didn't make it a child of the 
'Accessibility' page until just now):

http://live.gnome.org/Accessibility/BonoboDeprecation
http://live.gnome.org/AccessibilityCORBAToDBusMapping

Hope this helps,

Will

Luke Yelavich wrote:
> Hi all
> You may or may not be aware that the planning for Lucid Lynx is now under way. Lucid Lynx will be a long term support release, so many aspects of developing the distro are being done in a somewhat more conservative approach this cycle. Since Lucid will still be shipping GNOME panel et al , which requires bonobo etc, I am seriously considering remaining with at-spi in its current form, i.e using bonobo/orbit, for the single reason that it works well, and changing to the dbus implementation will break existing applications in Ubuntu like gok and dasher, since at-spi over dbus does not yet have a C library for client apps to link to, at least as I understand things.
>
> I would like to hear people's thoughts on whether this is the right approach. On one hand, I'd love to move over to the new implementation of at-spi, however since this is a long term support release, I really do not want to introduce possible breakage and regressions in some, if not all, use cases. I guess what I am asking for, is a convincing argument to move to at-spi over dbus. I am also interested from a distro packager's point of view, as to how easy it is to transition over. If its not much work to transition, and I can make the change early in the lucid cycle, to allow for testing, then I will certainly give weight to using at-spi over dbus, but as I've said, I am concerned about breaking otherwise working applications, especially in a long term support release.
>
> Thanks in advance for any thoughts/suggestions you may have.
>
> Luke
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list