> > This is definitely interesting stuff, and I'm looking forward to
> > performance studies and real world experience with the new work.
> Yes, me too.
> Do you have any idea how best to do a real word performance study?
Not sure, exactly. I would like to see some sort of comparison between
the CPU/Memory usage of the CORBA vs. DBUS based solutions as well as
overall speed/latency of communication between applications and
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. Off the
top of my head, I think the pairs of apps should probably be based upon
typical scenarios we run into:
1) Heavy text editing (e.g., a simple text editor, an office suite like
OOo, composing/reading e-mail)
2) Very bursty event activity (e.g., a terminal running 'top',
an IM client, etc.)
3) Simple control activity (e.g., using a GUI calculator)
4) Web access
> > I found the creation of a brand new API a cause for concern, however,
> > and have sent Harald a note on this.
> Trolltech told me that the API is extremely close to AT-SPI, and that they
> support everything that is in real world use in assistive technologies such
> as Orca.
That would be great.
> > While I'm awaiting a response, do you know if Trolltech is looking to
> > provide compatibility with existing AT-SPI-based assistive technologies such
> > as Orca?
> Binary compatibility with AT-SPI is impossible because of the use of ORBit2,
> but they said that it would be easy and straightforward to write a
> compatibility library based on IBM's recent Python bindings for
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
> Is Orca using any functionality that has been left out in IAccessible2 (and
> that isn't in MSAA either)? Then we need to check that it is also in the
> D-Bus API.
I haven't done a detailed comparison between IAccessible2 or AT-SPI, nor
have I really done an investigation of what portions of AT-SPI Orca uses
and does not use. 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.
kde-accessibility mailing list