[Kde-accessibility] Timeframe for KDE 4

[Bill Haneman]

Hi Gary, All:

I'll snip a bit, hope you can recall the context...

On Wed, 2006-02-22 at 17:25, Gary Cramblitt wrote:...
> 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?

I think it depends on the type of "AT application" you wish to write.  

When people say "assistive technology", they can mean different things. 
For the purposes of the discussion, we can distinguish between four
categories of "assistive technologies":

1) platform accessibility features, such as the "AccessX" features build
into the XKB X server extension, including SlowKeys, StickyKeys, and
MouseKeys.  These are unlikely to need to interface with QAccessible or
AT-SPI, as they are behaviors of the platform itself.

2) accessibility-related services, which are used by other applications
directly or by other assistive technologies (in categories 3 and 4
below); for instance KTTSD, gnome-mag, and brltty would be examples of
services which provide important support for assistive technology. 
Choice of APIs is vital to interoperability, but the existing "AT-SPI"
interfaces don't include these services, they are intentionally covered
by separate service APIs.  As relatively modular services, they also
lend themselves reasonably well to bridging as a means of ensuring
interoperability; see for instance the Speech Dispatcher back-end for
gnome-speech, and discussion of supporting Speech Dispatcher in KTTSD.

3) small "utility" programs that provide helper applications or
assistance in using some subset of the desktop environment; examples
might include the existing simple version of KMag, KMouth, KMousetool,
or a self-contained application for reading e-books.  While support for
QAccessible-type information via AT-SPI could enhance some of these
applications, they can do useful, though somewhat limited, work without
AT-SPI.

4) "full blown" assistive technologies, i.e. agents that interpose
themselves between the end user and one or more major input/output
modalities across the desktop environment.  These are the ATs that are
the end user's primary, or entire, means of interacting with the desktop
environment, and in that sense they are like full-spectrum "UI
Adapters".  Examples include screen readers, which replace the visual
user interface with spoken or brailled output; more advanced types of
full screen magnifiers, which do sophisticated focus tracking and high
levels of magnification; and adaptive onscreen keyboard such as GOK,
which replace the entire input method for the desktop.  These are the
ATs that require the full power of AT-SPI, and they are also the most
complex and difficult to write.  They are also arguably the most
important, in the sense that they bridge a bigger divide between the end
user and the 'traditional' GUI.

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

Speech-to-text seems to me like a good example of an assistive
technology "service", as in category 2 above.  We don't have a
speech-to-text or advanced-speech-recognition (ASR) API defined for the
free desktop yet, but it makes sense that we should.  So this example is
sort of a green-field one.  For existing service APIs other than AT-SPI,
I think porting/migrating to a DBUS-based service merits consideration,
and I think that it could be done in a coordinated way with the existing
service users (e.g. mostly the "Gnome" ATs) without sacrificing
interoperability.  Certainly for newly defined service APIs that don't
already have a proven implementation, DBUS seems like a logical choice.

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

Of course, the catch in the 'service' model above is that the end-user
gets no benefit unless some application is using that service.  For the
speech recognition to be usable in anything more than a simple plug-in,
some client of that service would need access to AT-SPI in order to
interface between the ASR service and the application. 

(There are a couple of 'service' APIs that _are_ included in AT-SPI
currently, which might be of interest to such a project - particularly,
the upcoming "Selector" interface.  We plan for GOK to expose that
interface, which means that an ASR client could use GOK's knowledge of
running applications in order to interpret spoken commands.)

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

In practice I don't see such a division between teams.  If someone on
the KDE team writes an AT-SPI client that uses KDE libraries, I have
little doubt that it would be welcomed by both desktop teams.  Perhaps
the only practical hitch would be that the project might need to be
hosted on SourceForge instead of the KDE repository.  As the dependency
issues get resolved to everyone's satisfaction, projects can migrate
from SourceForge (if there's a strong reason to do so).

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

As someone who is not a KDE developer per se, I have little to add
here.  But I do have doubts about the desirability of writing more ATs
in 'category 4', as opposed to improving/assisting those that we already
have.  Orca, for instance, doesn't have much Gnome-like about it; being
in python, the AT-SPI bindings just look like python objects.  IMO it
would be better for KDE accessibility to help the Orca team develop
better custom scripts for interacting with KDE applications (i.e. using
Phase A), so that blind users can use the KDE desktop.  I agree that
resourcing is not large; it's not big for the "gnome" ATs either, so
sharing ATs as well as APIs seems like the best approach.

Bill
> Thanks for listening.
> 
> -- 
> Gary Cramblitt (aka PhantomsDad)
> KDE Text-to-Speech Maintainer
> http://accessibility.kde.org/developer/kttsd/index.php
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility at kde.org
> https://mail.kde.org/mailman/listinfo/kde-accessibility