[Kde-accessibility] Re: KDE Interop [accessibility]

[Olaf Jan Schmidt]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Zack]
> > the project got stuck with not enough man power and the conclusion was
> > that it just makes more sense to do it natively (by the way if you
> > want to talk to that team the time is now

As maintainer of the KDE Accessibility Project, I would indeed like to=20
talk to them, but I simply don't know of any efford to implement such a=20
"native solution".=20

If KDE based accessibility aids won't work with AT-SPI based braille=20
device drivers, then all the efford is simply in vain, and=20
re-implementing something different would be no smaller efford.

Zack, I guess this is just a very big misunderstanding, but it would be=20
really nice if you could send me a mail explaining why you are maiking=20
this claim.


> > since they're starting coding native interfaces)

There already are native Qt interfaces. Our plan is to bridge them to=20
AT-SPI. This bridging code will very likely use ATK rather then Corba=20
directly, as we do not have enough manpower to write a new Corba=20
implementation for KDE.

AT-SPI is based on Corba, but our planned usage of Corba-based=20
technologies has nothing to do with whether we like Corba or not. There=20
simply is no other way to interoperate with Gnome and Java based=20
accessibility aids than via AT-SPI.

AT-SPI support for KDE is really a huge efford, and we are extremely short=
=20
of manpower. TrollTech offered help, but it is still unclear how much=20
efford they will really put into this. We are currently working on=20
different things that are less complicated, but eventually we plan to go=20
this road.



[Bill Haneman]
> James is right in a way, but the relative cost of effort is quite
> different between interoperability at the at-spi and ATK layers (choose
> one)...
>
> Bridging to AT-SPI is all well and good (it's what Java does now), but
> it's a lot more work and requires close monitoring to prevent serious
> behavioral inconsistencies.  It also means developing CORBA expertise
> and writing CORBA service code...
>
> I would think that the KDE team would find writing a CORBA-based plugin
> even more unsettling (and a lot more work!) than writing a plugin that
> had a glib dependency.  In general bridging to ATK is the more
> expedient solution, and also the nicer one in terms of code reuse
> (fewer bridges to maintain and test) and total size of the resulting
> distro.

I agree.

Olaf.

=2D --=20
Olaf Jan Schmidt, KDE Accessibility Project
KDEAP co-maintainer, maintainer of http://accessibility.kde.org

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj5mHREACgkQoLYC8AehV8fzEgCeJjHaQp1nW/5MCls02TQoM9d1
sWcAoJxq51kfZKXf19xhcGOpLjU8+xtB
=3DGrZ8
=2D----END PGP SIGNATURE-----