Re: [Kde-accessibility] Proklam and KMouth



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 Interface
> (which should really perhaps be called the GNU Accessibility Service
> Provider Interface) which is used by several assistive technologies (such
> as Gnopernicus - the GNOME Screen reader/magnifier; and GOK - the GNOME
> On-screen Keyboard) to get access to all of the applications written using
> 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 assistive
> technologies.
>
KMouth is a KDE program. That does not mean that I do not want to provide 
support for GAP (Quite the opposite: it would be great if KMouth would 
support GAP). However, I think the support for GAP would be better suited 
inside qt or in basic KDE classes. As I am not familiar with GAP, I do not 
know how much work it would be to support GAP directly. If it is not too much 
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 
(parallel to the support of Proklam) or as a Proklam plug in. I will discuss 
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 
library. However, I do assume that it would be much work to implement the AT 
SPI support in qt/kde. Therefore that might be a goal for the future. In the 
meantime I have to get more information about the AT SPI, so that I can 
decide whether a direct support inside KMouth can be done with a reasonable 
amount of work, as I do implement KMouth as a project besides my studies.

Gunnar Schmidt



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]