[Kde-accessibility] Timeframe for KDE 4

[Gary Cramblitt]

On Tuesday 21 February 2006 18:20, Gunnar Schmi Dt wrote:
> For the purposes of the TWG we can summarise the AT-SPI-related discussion
> as follows:
>
> The AT-SPI integration needs to be done in two distinct efforts:
>
> a) In order to enable AT-SPI-based assistive technologies to work together
> with KDE applications we can make use of the QAccessible framework.
> Basically this involves implementing accessibility-related information for
> all KDE widgets.
>
> This effort can be done without changing the API, but it needs to be
> completed before we release KDE 4. (Otherwise we would disappoint the
> people who expect KDE 4 to be as accessible as GNOME -- as we have told
> since about two years.)

Sorry, I'm a little confused.  In phase A, what happens to the existing KDE AT 
applications (KMag, KTTS, etc)?  How do they make use of the QAccessible 
framework?  I was under the impression that as a minimum we'd need the Qt/ATK 
bridge (non DBUS) that Harald Fernengel implemented last year.  See Bill's 
response in this thread.  Or are you suggesting that in phase A, KDE AT apps 
not interface with ATK/AT-SPI?

>
> b) Enabling our assistive technologies to make use of AT-SPI is more an
> open problem. AT-SPI is currently based on CORBA. As a long-term goal it
> is planned to move AT-SPI to DBUS, but this requires to write an IDL
> compiler for DBUS first.

I'd like to look at this from the standpoint of a KDE developer wishing to 
write AT applications for KDE4, or incorporate AT into KDE applications.  
Will KDE4 permit me to do that and what does the interface look like?  What 
libraries, compilers, etc. will I need and what dependencies will my 
application have?  Given the level of effort to implement phase B, and the 
need to coordinate with Gnome AT developers, it seems likely that phase B 
won't be completed in time for the first release of KDE4.  What, if any 
options will I have then?

Let's say for example that I want to implement a speech-to-text capability for 
KDE.  I might base it on Sphinx.  My goal is to implement the STT capability 
in such a way that it works with all KDE applications.  If it also works with 
Gnome applications, that's a bonus.  So the AT-SPI seems like the best way to 
implement it.  How would I go about implementing my STT capability if only 
Phase A is in place?  If I understand what you and Bill Haneman are saying, 
with only Phase A in place, I'd have to install Harald's Qt/ATK bridge, 
install and compile my program against the ATK, and also install AT-SPI, 
together with all the Orbit/Gnome dependencies these components bring in.  My 
users will of course also have to install these components.  Will I be able 
to commit my code to the KDE repository, or will I be banished to 
extragear/playground because of the dependencies.  If this is the case, I 
have little incentive to write my application for KDE.  I might as well go 
join the Gnome developer's team where I can get better mainstream exposure 
for my application.

I'm not asking all these questions in order to complain or throw cold water on 
the plan.  Partly, its for my own clarification, but mostly I'm asking all 
these questions because I want the TWG and board to understand the issues and 
the ramifications.

I think it comes down to this (but I might be wrong).  Phase A permits KDE 
applications to work with Gnome AT applications.  For instance, if I install 
all the dependencies, I'll be able to use the Orca screen reader with KDE 
applications.  However, if I want to write a KDE AT application, it will be 
heavily dependent upon Orbit/Gnome components.  What will be the TWG's policy 
or strategy for handling such applications?  Will they be banished to 
extragear/playground?  Will the TWG recommend waiting for Phase B?

Thanks for listening.

-- 
Gary Cramblitt (aka PhantomsDad)
KDE Text-to-Speech Maintainer
http://accessibility.kde.org/developer/kttsd/index.php