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

[Pupeno]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 26 November 2002 12:47, Bill Haneman wrote:
> 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.
Well, I should see the advantages and disadvantages of having the 
accessibility code in kde's core or not. It wouldn't be a problem for 
compiling, if ATK is not found is not compiled, simple, but it would be a 
problem for packaging. Do you have any idea of the advanteas of calling ATK 
API directly from KDE core ?

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

Oh, ok, if you say so, I didn't check this issue yet, I was based on your own 
words. So, if you say ATK completly implements all that is needed from 
AT-SPI, I'll take your word as true. :)

> > 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...
I see, good point, thank you for showing that up.
Why does ORBit2 depends on glib ? (just curiosity).
If I'm going to choose to go with ATK (as it seems I'm going to do) I'd like 
to know about ATK development cycle, anything you could tell me would be 
usefull (I'm running out of time, but later, I'll suscribe to gnome mailing 
lists about this). Specially, I'd like to know how ATK is released and/or how 
is going to be released.
Thank you.
- -- 
Pupeno: pupeno@pupeno.com
http://www.pupeno.com
- ---
Help the hungry children of Argentina, 
please go to (and make it your homepage):
http://www.porloschicos.com/servlet/PorLosChicos?comando=donar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE947wFLr8z5XzmSDQRAt6+AKC+7gVYi+zp61w1b74fPNOosGfrqgCfRcyj
rm9uEETsOwiLwZ9MgXjExvU=
=aGXZ
-----END PGP SIGNATURE-----