[Kde-accessibility] Some AT-SPI questions

[Bill Haneman]

Hi Gary;

I'll try to give some initial thoughts on your points (#1 through #3) 
below.  They seem right on target to me.

The only thing that strikes me as possibly a little odd is the 
continuing use of the term "KDE developers" in the context of AT 
clients.  I would prefer to just say "developers" in this context; in 
what sense are they "KDE" rather than some other sort of developer, or 
perhaps new developers without such a strong "brand loyalty" ?

In the context of making KDE applications (apps that are part of KDE, or 
are built with Qt, etc.) accessible, the notion of "KDE developer" makes 
a lot of sense.  But of course assistive technologies can be built 
without using either gtk+ or Qt, and they may use a mix or libraries and 
services traditionally considered part of Gnome and/or KDE. 

Perhaps the question, from the _client_ point of view, is "how can I 
write AT clients which use Qt", and "how can I write AT clients which 
use gtk+"?  Ideally the interfaces those two kinds of AT clients use to 
talk to the AT-SPI subsystem will be the same - if not immediately, then 
certainly eventually. 

Rather than make a "Gnome screenreader" and a "KDE screenreader", which 
IMO dilutes our efforts, I would hope that our AT development efforts 
would try to combine forces where possible.  I think that this is 
already happening and I am very glad to see it.  For instance the orca 
screenreader doesn't currently present any GUI at all, and although it's 
hosted at cvs.gnome.org, about the only gnome-ish thing about it is the 
use of the pyOrbit bindings to AT-SPI.  So I don't see why it can't talk 
to, for instance, a Qt-based magnifier service or SpeechDispatcher or 
KTTSD if that makes sense.... just to give some examples.

Okay, enough rambling, I'll make some comments inline...

Gary Cramblitt wrote:

>Thanks Bill.
>
>It would be nice if someone fully knowledgeable about the KDE plan could 
>update the accessibility.kde.org website and explain all this so we 
>developers can have a better understanding.  I'm sure the following exposes 
>my ignorance, but as they say, there are no stupid questions..  
>
>I *think* it breaks down to 3 possible scenarios:
>
>1.  How can KDE developers write KDE 3 AT clients today (using ATK bridge)?
>  
>
The ATK bridge isn't needed by the AT client; it is used to 'export' 
accessibility info from ATK-implementing applications to AT-SPI.  So an 
AT client using the KDE 3 libraries would need, at present, to speak the 
AT-SPI "interface protocol", the simplest way is to link to libspi 
(which for the time being pulls in ORBit2) or to use other bindings such 
as the pyOrbit bindings.

>2.  How can they develop AT clients with KDE4 libraries in conjunction with 
>Gnome libraries?
>  
>
Are you sure you are talking about AT clients here?  The existing AT 
clients should work with KDE4 applications, because the KDE4 apps will 
export AT-SPI information via (if I understand Harald's work correctly) 
ATK and the atk-bridge.  The clients won't "see" the bridge, but they 
will need one of the AT-SPI bindings in order to "communicate" with the 
AT-SPI subsystem.  So in KDE4, the big change will be that ATs will be 
able to work properly (disregarding, for the moment, bugs) with KDE 
applications.

>3.  How will KDE devs develop AT clients when the AT-SPI DBUS version is in 
>place and how do we get there?
>  
>
This is an interesting question and a tough one.  Ideally we don't want 
to have to re-write existing ATs or break interoperability, so we want 
the AT-SPI interfaces as seen by ATs to change as little as possible.  
At the same time, we want them to be as "generic" as possible, which 
from a KDE perspective probably means reducing the dependency on Gnome 
libraries as much as possible.  I don't think this is because of an 
anti-Gnome sentiment, at least I hope not, but rather it reflect the 
fact that nobody wants to pull in a lot of new dependencies which they 
are not otherwise using, and I respect this. 

I agree however that it's not trivial to do.  Two approaches that come 
to mind:

1) IDL compiler generates new client stubs whose API signature, at least 
in C and Python, matches the existing C and Python CORBA stubs; ATs then 
only need to re-compile in order to work using the new backend (which 
would presumably use DBUS as its IPC transport). 

2) Keep ORBit2, but change its internals so that an "ORBit2-lite" 
implementation which doesn't use IIOP is available, and replace the IIOP 
wire protocol with DBUS.  This would eliminate most of the stuff in 
CORBA which people think is broken IMO, except for the ugly C bindings 
(which might be unavoidable, C being the non-OO language that it is).  
If we "fix" the C bindings, then we break compatibility and have to 
re-write apps, so that's not an attractive idea anyway.  The pyOrbit 
bindings look the same, so apps like orca don't really have to do 
anything, it "just works".

I suspect #2 is the more feasible way to go, but it would mean that the 
"shell" of ORBit2 would end up living on as part of the accessibility 
infrastructure.  Some people might be unhappy with this, but it seems 
more practical to me than writing an IDL compiler, unless there are 
other good reasons for doing so.  Perhaps the combined Gnome+KDE forces 
have enough interest in making DBUS more programmer-friendly that this 
bigger job will happen anyway.  I have heard rumors of IDL compiler work 
going in in the DBUS space but I don't know any hard facts about it.

Best regards

Bill

>The IDL compiler approach strikes me as the most plausible way forward for #3.  
>I say this because very few people in the KDE community understand 
>Bonobo/ORBit2  enough to do the port.  Is anyone working on such a compiler?  
>How difficult would it be to do that and how would one get started if one 
>were inclined to work on it?
>
>If anyone wants to write this up (whatever format you like), I'd be happy to 
>post it on the website.
>
>  
>