[Kde-accessibility] Timeframe for KDE 4

[Gunnar Schmi Dt]

Hello Gary,

On Wednesday 22 February 2006 18:25, Gary Cramblitt wrote:
> On Tuesday 21 February 2006 18:20, Gunnar Schmi Dt wrote:
> > [...]
> > 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.
> >[...]
>
> 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?

I was thinking more along the lines of two different efforts that can be 
done in parallel. If we want the usual KDE developers to test the 
accessibility of their application we might need to provide them with some 
at-poke tool without large dependencies (not every KDE developer wants to 
install GNOME just for testing the accessibility of one application), so 
we need to tackle effort b) in any case.

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

One possible option for effort b) would be to write a small wrapper library 
that provides a subset of AT-SPI (only the features that are really needed 
by the KDE AT applications). In that case we can change the implementation 
of the library to DBUS later without changing the AT applications.

> 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.
>  [... something about the lines of CORBA / glib dependencies ...]
>  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.
> [...]

That is definitely part of effort b). No matter which what we implement for 
KDE based AT applications, we need to make sure they can be included in 
the kdeaccessibility module.

We need to solve both effort a) and effort b) before we release KDE 4. 
Given the small number of KDE AT applications we might be able to live 
with an interim solution for effort b), though.

Gunnar Schmi Dt
-- 
Co-maintainer of the KDE Accessibility Project
Maintainer of the kdeaccessibility package
http://accessibility.kde.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-accessibility/attachments/20060222/4dfc1414/attachment.pgp