Hi!

I am probably still misunderstanding some things, so I am summarising what I 
have understood so far of the whole AT-SPI picture. This email functions both 
as an attempt to find possible misunderstandings, and as an explanation why 
it is important for KDE to move AT-SPI onto D-Bus. Please correct all wrong 
assumptions, and keep in mind that I have no power to tell Trolltech what to 
do with AT-SPI.

Imaging a new, much improved version of kmousetool talking to KOffice on a KDE 
desktop on FreeBSD or IBM AIX.

The GNOME accessibility team suggests to implement AT-SPI support in Qt by 
linking to ATK. This requires significant changes in glib and/or ORBit2, and 
significant effort for the Qt-ATK bridge. It would also only deal with the 
application side. Doing a move to D-Bus later would be the same amount of 
work as doing it now, meaning that going for D-Bus directly takes 
significantly fewer resources altogether.

GNOME applications read a gconf key to check whether AT-SPI is enabled. Do 
they also watch changes of the gconf keys during runtime in case the setting 
gets changed? And what do non-GNOME applications do instead?

The assistive technologies use Bonobo-activation to start the AT-SPI registry. 
Does this mean either linking to libbonobo or reimplementing it with a 
different ORB?

There is no complete C++ ORB that runs on all platform KDE targets, which 
means we have five options:
1. Abandon all plans that we have for assistive technologies.
2. Put a lot of work into a solution that works on only some of our target 
platforms.
3. Make KDE applications support both Bonobo-AT-SPI and D-Bus-AT-SPI. This 
would mean doing twice the work for only half a solution, because GNOME 
applications would still fail to work with KDE-based assistive technologies.
4. Write an incompatible version of AT-SPI.
5. Convince GNOME to join us in our move to D-Bus, which means work on the 
framework now, but significantly fewer work for the authors of KDE-based ATs 
later.

The GNOME accessibility team suggests to make the CORBA- and Bonobo-based 
version of AT-SPI a part of the LSB standard, which also means standardising 
all dependencies of the AT-SPI registry. Which exactly are these?

The LSB requires interfaces to be around for at least 6 years, which means 
that a D-Bus-based version of AT-SPI would be non-standard until at least 
2013.

ORBit2 is described by Michael Meeks as not sufficiently documented, virtually 
unmaintained and only a "subset" of the OMG specification. Which role does 
Michael Meeks have among the ORBit2 developers?

I once suggested to reduce the number of dependencies the AT-SPI registry has, 
and Bill Haneman answered that this doesn't make sense since our long-term 
goal is D-Bus anyway. Or did I misunderstand him?

Bill also say that a D-Bus-based variant of AT-SPI is not a real AT-SPI. How 
does this fit to the agreed "many worlds" approach? Or did he only mean that 
we should use an IDL compiler for themove to D-Bus?

I know that the GNOME team has spent a lot of time for discussing 
interoperability with KDE, and I truly thankful for that. I also appreciate 
the offer for constructive discussion of the obstacles towards AT-SPI use in 
Qt and KDE.

And please don't see our push for a D-Bus-based as an attempt to create 
incompatibilities. Quite the contrary - it is a compliment that we plan to 
make the excellent work of the GNOME accessibility team useful for us.

Summary: My fear is that implementing the AT-SPI support in Qt via ATK 
initially will make it impossible to prevent LSB cementation of 
Bonobo-AT-SPI, which would totally evaporate the goodwill towards AT-SPI that 
we have build within the KDE community. Making the decision to go directly 
for D-Bus is certainly not popular with everyone, but it might be the wisest 
course in a long-term perspective.

Olaf

-- 
Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards 
accessibility networker, Protestant theology student and webmaster of 
http://accessibility.kde.org/ and http://www.amen-online.de/
_______________________________________________
kde-accessibility mailing list
kde-accessibility@kde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility