[Kde-accessibility] Some AT-SPI questions

[Gary Cramblitt]

On Friday 16 December 2005 10:43, Bill Haneman wrote:
> Hi Gary;
>
> I'll try to give some initial thoughts on your points (#1 through #3)
> below.  They seem right on target to me.
>
> The only thing that strikes me as possibly a little odd is the
> continuing use of the term "KDE developers" in the context of AT
> clients.  I would prefer to just say "developers" in this context; in
> what sense are they "KDE" rather than some other sort of developer, or
> perhaps new developers without such a strong "brand loyalty" ?
>
> In the context of making KDE applications (apps that are part of KDE, or
> are built with Qt, etc.) accessible, the notion of "KDE developer" makes
> a lot of sense.  But of course assistive technologies can be built
> without using either gtk+ or Qt, and they may use a mix or libraries and
> services traditionally considered part of Gnome and/or KDE.

Agreed, and no desktop bias was intended.  I was looking at it from Leo's 
perspective, who I assume is a Qt/KDE developer.

>
> Perhaps the question, from the _client_ point of view, is "how can I
> write AT clients which use Qt", and "how can I write AT clients which
> use gtk+"?  Ideally the interfaces those two kinds of AT clients use to
> talk to the AT-SPI subsystem will be the same - if not immediately, then
> certainly eventually.
>
> Rather than make a "Gnome screenreader" and a "KDE screenreader", which
> IMO dilutes our efforts, I would hope that our AT development efforts
> would try to combine forces where possible.  I think that this is
> already happening and I am very glad to see it.  For instance the orca
> screenreader doesn't currently present any GUI at all, and although it's
> hosted at cvs.gnome.org, about the only gnome-ish thing about it is the
> use of the pyOrbit bindings to AT-SPI.  So I don't see why it can't talk
> to, for instance, a Qt-based magnifier service or SpeechDispatcher or
> KTTSD if that makes sense.... just to give some examples.

I'm with you here Bill, and didn't intend to imply otherwise.

BTW, I've been working with Hynek Hanke to develop some additional 
capabilities in Speech Dispatcher so that KTTSD can use it for its speech 
backend.  The idea is that Speech Dispatcher would be the core speech backend 
for both KDE and Gnome.  (I've heard there is a SD plugin for Gnome Speech in 
development?)  I believe SD is a good choice because it has proven 
capabilities and performance for screen readers.  It also is desktop 
independent and can provide speech services from near bootup (although it 
isn't built into the kernel) and in consoles.  KTTSD's role then reduces to:

  1.  Provides a simple API for speech-enabled KDE applications to use.  
Presently, DCOP, but probably DBUS in the future, or maybe both.  Decisions 
haven't been finalized.  For performance reasons, I believe AT clients such 
as screen readers should bypass KTTSD and interface directly with SD.

  2.  Interfaces with KNotify, the KDE notification subsystem.

  3.  Provides enhanced text filtering and transformation services.  xhtml to 
ssml, for example.

The queuing and prioritization functions disappear from KTTSD; they will be 
handled by SD.

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