[Kde-accessibility] AT-SPI, to ATK or not to ATK...

[Bill Haneman]

Hi Pupeno, thanks for looking at this.

I have a few comments which I hope may be helpful.

> Well.
> In the last meeting on IRC I was selected to be in charge to organize the
> efforts to implement AT-SPI on KDE.
...
> The question is simple, we have two options.
> Go directly to AT-SPI, and having to deal with CORBA, which seems to be
> complex (I don't know about CORBA, can anybody experienced in this give me an
> overview of how complex CORBA is ?) or we can use ATK (which is much simpler
> than CORBA acordding to Bill).
> The problem with ATK is that is part of the gnome project (and is gobject
> based) so, that will make KDE dependant on Gnome, or at least, KDE
> Accessibility dependant on Gnome's libs, the advantage is that ATK is much
> simpler to code and the ATK->AT-SPI is already working (acording to BILL).

Remember that this doesn't mean that any other part of KDE would incur a
dependency on glib+ATK; only the KDE accessibility code, which could be
a dynamically linked library, etc.  You might not want KDE to call
directly into ATK API (though there are also advantages to this), and I
assure you that this separation could be maintained everywhere but
inside the accessibility libraries themselves.

> The other disvantage I may see on this aproach is that we would like to have
> a diferent aproach than ATK, add something, etc, etc. ATK doesn't implement
> all the functionality that AT-SPI implements. I don't think we'll need
> something that ATK doesn't provide, but if we do, we'll be stuck.

I don't really understand this point; ATK does indeed implement
everything AT-SPI needs, with the exception of API that does not belong
in the user-interface toolkit at all.  The parts of at-spi that aren't
mapped into ATK are parts that don't belong in the user interface
toolkit anyhow.  And of course in order to be compatible you will be
restricted to what AT-SPI can express.  So I see no restriction in using
ATK in this way at all.  I should point out also that ATK is a
dynamically extensible API, that is, new ROLE, STATE, etc. types can be
added at runtime.  However one shouldn't rely on this too heavily since
the assistive technology clients can't be expected to know what to do
with these new types...

> The problem of going directly with CORBA is that CORBA is too complex and I
> don't want to be lost in a huge problem. KDE Accessibility would depend on
> Corba, but depending on Gnome it depends on CORBA anyway. The advantage here
> is the dependency of ATK/Gnome and the posibility of use another architecture
> diferent to ATKs.

If you use an architecture different from ATK then you will encounter
other problems.  ATK and AT-SPI are very similar in features (one-to-one
mapping except as mentioned above), and any accessibility API that you
want to bridge to AT-SPI should be just as similar.  Thus KATK would
look almost identical to ATK... so why duplicate all that code just to
avoid a single library dependency?

Exporting AT-SPI from KDE would be more dependency-clean in the sense of
libraries, but then you would depend on some CORBA ORB, probably ORBit2
since it's fast and lightweight and free, and already bundled with most
Linux distributions.  But of course ORBit2 links to glib, and many other
parts of GNOME... 

The "java-access-bridge" which exports AT-SPI for java applications uses
this "bridge to AT-SPI" approach, but the Java VM has its own ORB built
in, and being a Java system it would have difficulty using a native-code
ORB's C or C++ bindings anyway.

> So, I think this decition will depend in a lot of things, including, how many
> people want to work on implement this... if I'm alone, or alone with Gunnar
> (wich is already working on other things as well as I am) going with CORBA,
> something I don't know and I belive that Gunnar doesn't know either will be a
> very hard task.
> So, I'd like to like your opinions and points in this issue.
...
> PS: couldn't we 'simple' port ATK to KDE ? making KATK, KDE Accessibility 
> ToolKit (let's remove the last K, KAT, nice, hu ?)

I don't see any reason to do this duplication of effort, which would
then require its own KAT-to-AT-SPI bridge; in this case you get to do
*both* of the tasks above instead of just one or the other!  It would
give you a more KDE-centric solution but I don't see that as adding any
value for the user.

regards,

Bill
 
> PSPS: does anybody know where the AT-SPI documentation can be found ?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQE946rKLr8z5XzmSDQRAj7gAKDAv268k0xBe3gCmikgxn5w1VxKOACdGAZZ
> B9QROAAz0Mc7AjbXtxvUdEM=
> =ZMEG
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-accessibility