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
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
_______________________________________________
gnome-accessibility-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
