[Kde-accessibility] Proklam and KMouth

[Gunnar Schmi Dt]

Hello Peter,

Thank you for you mail.

On Monday 23 September 2002 08:01, Peter Korn wrote:
> Hi Gunnar,
>
> Good to hear about your KMouth project to provide augmentative
> communication functionality in the Linux environment.  [...]
>
> I highly recommend you check out the GNOME Accessibility work (see
> http://developer.gnome.org/projects/gap).  The GNOME community is
> developing a rich accessibility infrastructure on top of the GNOME 2
> library stack, including the GNOME Accessibility Service Provider Inter=
face
> (which should really perhaps be called the GNU Accessibility Service
> Provider Interface) which is used by several assistive technologies (su=
ch
> as Gnopernicus - the GNOME Screen reader/magnifier; and GOK - the GNOME
> On-screen Keyboard) to get access to all of the applications written us=
ing
> the GTK+ libraries, Java Swing libraries, as well as StarOffice and
> Netscape.  User-interfaces which support the AT SPI (either directly or
> through one of several bridges) would therefore work with these assisti=
ve
> technologies.
>
KMouth is a KDE program. That does not mean that I do not want to provide=
=20
support for GAP (Quite the opposite: it would be great if KMouth would=20
support GAP). However, I think the support for GAP would be better suited=
=20
inside qt or in basic KDE classes. As I am not familiar with GAP, I do no=
t=20
know how much work it would be to support GAP directly. If it is not too =
much=20
work, then it might be an option.

> Also part of the GNOME Accessibility work is the gnome-speech project,
> which provides an API to text-to-speech engines (both software and
> hardware). [...]
>
Support for gnome-speech could be either implemented as part of KMouth=20
(parallel to the support of Proklam) or as a Proklam plug in. I will disc=
uss=20
this question with the Proklam developer.

> It would be great if KMouth could work with gnome-speech, and thereby
> support all gnome-speech synthesizers.  And, especially if you are
> concerned about finding ways for users with limited physical dexterity =
to
> drive the KMouth interface, you might consider supporting AT SPI. [...]
>
As I have said, support for the AT SPI would be suited inside the qt/kde=20
library. However, I do assume that it would be much work to implement the=
 AT=20
SPI support in qt/kde. Therefore that might be a goal for the future. In =
the=20
meantime I have to get more information about the AT SPI, so that I can=20
decide whether a direct support inside KMouth can be done with a reasonab=
le=20
amount of work, as I do implement KMouth as a project besides my studies.

Gunnar Schmidt