Re: [Accessibility] Re: D-Bus-based accessibility API

> If you can plug either API implementation (D-Bus or CORBA) into a common
> interface, then it should be possible to make the code work reasonably
> using either.  Why wouldn't it be possible to test with the same
> application?  The only difference should be the transport mechanism.

This possibility doesn't exist today.  :-(  The AT-SPI infrastructure
speaks CORBA and there is not a DBUS solution for it.  We were operating
under the belief that Trolltech was working on a DBUS-based solution
that would be compatible with the AT-SPI infrastructure.  This would
have been fantastic and a wonderful community-oriented approach.  I was
really looking forward to it in a very positive manner.

>From what I can tell, it turns out this was a false belief.  From seeing
the work on QDasher (a port of Dasher to the new Trolltech API), it
seems Trolltech's approach is to port assistive technologies to a new
API.  If true, that implies rewriting Orca to work with KDE. 

As I understand it, the Trolltech API is basically the same as existing
APIs.  As a result, there exists a potential opportunity to do several
things.  These include two snarky-ish things and one I'd like to see
(you guess which one I'd like to see ;-)):

1) Require all users who run GNOME and KDE applications to use two
assistive technologies simultaneously: one for GNOME and one for KDE and
just learn to live with the differences.

2) Rewrite the whole world all over again to do the same thing as AT-SPI
but use Trolltech's solution.  This might potentially be limited to just
rewriting ATK (used by GTK+, Mozilla, and OpenOffice), Java platform
support, pyatspi, and cspi.  It could, however, also require rewriting
all existing assistive technologies that currently use the AT-SPI.
After several years of debugging by a mythical army of developers with
unlimited funding, we'd be where we are today, but KDE would also be a
player in accessibility.

3) Provide support in pyatspi to allow pyatspi-based assistive
technologies to work with both the AT-SPI and Trolltech solutions
without needing to know what they are working with.  This would keep
compatibility with pyatspi-based assistive technologies and help get us
closer to KDE accessibility much faster.  If it turns out that the
Trolltech solution performs substantially better, AT-SPI-based toolkits
and apps could migrate to the new solution at their own pace.

My main motivation here is end users.  I care about end users and
getting them a compelling free open source solution _today_.  Rewriting
the infrastructure to make it the same, but different, just keeps
delaying this.  If changes must be made, we should give great
consideration to compatibility with existing assistive technologies.

> I think the big advantage to having a common interface is that we get
> better cross-platform testing and we have better opportunities to catch
> and fix bugs at the lower level.  Further, the GNOME community has long
> wished to move away from bonobo, and the existing GNOME AT infrastructure
> is probably the biggest roadblock to deprecating it.  I know the GNOME
> community would love to move to a D-Bus backend.  Though, until Java
> converts to D-Bus I think the need for the bonobo backend won't go away
> (at least for Sun).

I think we need to tease apart what people mean by "Bonobo".  The AT-SPI
infrastructure has two main components:  the activation/discovery of
clients and services and the communication between the various
components.  Bonobo is used for the activation/discovery and CORBA is
used for the communication.

Recent work on making all clients on a user's display visible to
assistive technologies (see
http://bugzilla.gnome.org/show_bug.cgi?id=163132), has laid the
groundwork for eliminating the Bonobo dependency.  In a discussion with
Bill Haneman last week, it seems as though we can get rid of Bonobo
altogether, leaving us with just CORBA.  I've informally proposed
eliminating the Bonobo dependency altogether for GNOME 2.22, and the
response is positive so far.

In any case, the introduction of IAccessible2 as well as Trolltech's new
API, combined with the desire for cross platform applications and
toolkits to have good support for accessibility, has served to help
create a disruptive moment for us to take pause and discuss.
Maintenance of code to handle cross platform accessibility is a
reasonable concern.  As I understand it, Mozilla is handling it by
providing an accessible core with thin IAccessible2 and ATK wrappers.

Back to hammering away on Orca with me.  People are really liking the
fact that it works and is providing usable access to a free and open
source desktop _today_.

Will