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

[Brian Cameron]

Olaf/Willie:

> [ Willie Walker, Di., 14. Aug. 2007 ]
>> Given that it sounds like the Trolltech API and the AT-SPI are identical
>> for the intents and purposes of such testing, I'd guess one could pick
>> several pairs of apps (one from GNOME, same sort of one from KDE) and
>> conduct studies such as latency, packet size, CPU usage, memory usage
>> and the user and assistive technology interact with the apps.
> 
> The difficulty, of course, is then that we are dealing with different 
> applications which might have speed differences themselves. So we are not 
> truly testing the speed of the 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.

I think this degree of abstraction is useful since for different
situations, it might make sense to use different IPC mechanisms.  For
example, for Java applications, it might be better to be able to use CORBA
which Java supports and the existing Java Accessibility code currently uses.
Rewriting Java to use D-Bus might be a long term possibility, but if you
make your infrastructure work with CORBA, then you will have better Java
accessibility support.  This might not be exciting to anybody but Sun, but
perhaps if the need to have a plug-inable interface for IPC in KDE were made
more visible here at Sun, it would get some more attention.

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

>> Yep!  That's why I proposed/pushed for the creation of the pyatspi
>> bindings and why we purposely tried to hide CORBA/ORBit/Bonobo stuff.
>> Knowing the current implementation of pyatspi, I suspect it may become a
>> bit of work at the pyatspi binding level to handle both the CORBA and
>> DBUS solutions.
> 
> Yes, it might indeed be a bit of work, especially if we want to use both of 
> them at the same time.

It probably doesn't make sense to use them both at the same time for the
same process.

>> Based upon the Hawaii conversations, I think the main design consideration
>> was that AT-SPI would be the assistive technology API and
>> splintering/subsetting/reinventing wouldn't happen. 
> 
> Trolltech is not reinventing the API - they are just using IAccessible2 as 
> their main target API. 

pyatspi is probably not the only way that a common interface could be found.
Perhaps there is a better way?

> I also have to say that I am no longer convinced that the roadmap we discussed 
> in Hawaii is still the best way forward. The KDE accessibility team spent a 
> lot of time coding to this roadmap last year. We began to implement an IDL 
> compiler for D-Bus because we were told that this helps GNOME to make the 
> port a common effort. Looking back, I am thinking that it would have been 
> wiser to spent this time on other accessibility issues.

Sun has invested a great deal of effort in creating the existing accessibility
infrastructure.  First in Java, then in GNOME.  I was involved with coding the
original implementation of libgail (the GtkTextView and GtkTreeView
implementations), and I remember feeling similarly as you describe about
other distros not participating enough.  However, today I think there is
much wider involvement.  I know Ubuntu is engaged with doing a lot of
accessibility related work these days.

At the moment, Sun is investing a lot of its accessibility energies in making
Firefox 3.0 accessible, trying to keep GOK maintained, developing orca, and
doing a considerable amount of QA testing and bug fixing.  I think that this
sort of project would be an area where Sun could be more involved.  That's
just my opinion, but perhaps if these issues were brought up on
desktop-discuss at opensolaris.org (which I've cc:ed) you might get a wider
audience of those people at Sun with an interest in helping.  I don't think
many of them pay close attention to accessibility specific mailing lists.

> I think that the Hawaii plan would have been perfect if we had all agreed to 
> implement it. But we have wasted several years failing to understand each 
> other and unable to cooperate on this, and so I would advise people not to 
> continue with the Hawaii road until there is a clear indication that the 
> AT-SPI developer community is seriously supporting a D-Bus port.

I'm sorry to hear that the plan hasn't been going well so far, but I think
you should not get discouraged.  I think there is value in this project, and
I suspect it will get done eventually.  Even though Section 508 compliance is a
really good selling point for free software, it doesn't seem that it gets
the attention it deserves a lot of times.

Brian