Re: KDE Interop [accessibility]

[Bill Haneman <bill haneman sun com>]

Zack said:
> 
> Accessability is really not my area in KDE so first of all let me put 
> this disclaimer here : "All opinions in this email are my own and in no 
> way express the stance of the KDE as whole. I speak on behalf of me and 
> not the KDE project" :)
> 
> Now to the point - those things are impossible to discuss without any 
> kind of design. But the way our accessability people wanted to do it 
> was to add a compile time option to make a binary plugin that bridges 
> Qt and ATK (I don't think Qt using Pango is realistic). So Qt would 
> never even see any GObjects and there still were people dissatisfied 
> with adding another plugin to Qt and 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 since they're starting coding native interfaces) 

This is not my understanding of the current plan.  If indeed there are
KDE folks who are writing accessibility code that does *not* bridge to
ATK then they need to raise this discussion on kde-accessibility kde org
and also talk to me.  

The alternative involves a *lot* more engineering effort and is likely
to result in poorer interoperability.  It's an enormous job already, so
the cost of something like ruling out an ATK plugin because of its glib
dependency could spell doom for the effort.

> So, yes, GObject seems to be a big problem for adopting GNOME 
> technologies and pitching a technology using GObject to KDE is going to 
> be incredibly hard (even for such a wonderful project as GStreamer) for 
> you guys.
...

> Zack 
> 

James said:

> 
> As far as accessibility goes, it might make more sense for KDE to look 
> at compatibility at the AT-SPI layer, rather than ATK layer.  This is 
> what the Sun guys are doing to hook Java a11y into the system, and 
> should let all the a11y tools work with KDE apps.  Of course, Bill 
> Haneman is the expert in this particular area.

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.

-Bill

> James.
-- 
Bill Haneman <bill haneman sun com>