Re: KDE Interop [accessibility]

Hash: SHA1

> > 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 
talk to them, but I simply don't know of any efford to implement such a 
"native solution". 

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

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

> > since they're starting coding native interfaces)

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

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

AT-SPI support for KDE is really a huge efford, and we are extremely short 
of manpower. TrollTech offered help, but it is still unclear how much 
efford they will really put into this. We are currently working on 
different things that are less complicated, but eventually we plan to go 
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 Jan Schmidt, KDE Accessibility Project
KDEAP co-maintainer, maintainer of

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]