[Kde-accessibility] Proklam and KMouth

[Bill Haneman]

On Mon, 2002-09-23 at 12:42, Gunnar Schmi Dt wrote:
...

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

Hi Gunnar:

I do hope that you will look closely at the GAP APIs and services.  I
believe this could prevent significant duplication of effort.

I believe that Peter's suggestion was more along the lines of using
gnome-speech within KMouth.  Gnome-speech is a speech service API
suitable for use with multiple voices and speech engines, with currently
available drivers for FreeTTS, Festival, and ViaVoice/Eloquence. 
Drivers for other text-to-speech engines and hardware devices are
anticipated.

If you prefer not to use gnome-speech's implementation directly, I would
still urge you and/or Proklam to use its APIs, which are defined in IDL;
this would ensure that the systems would interoperate correctly with
each other.
 
> > 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.

I believe that having a Proklam back-end for gnome-speech would make
more sense than vice-versa, since gnome-speech is a cross-process API
which is currently exported vi CORBA.
 
> > 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.

I believe also that Peter's suggestion is that KMouth could be a client
of AT-SPI; AT-SPI would give KMouth a rich source of application
information and a control API allowing it to take advantage of GOK (the
GNOME Onscreen Keyboard) and other "hands free" control technologies.

There has been discussion in the past, on this list and on the Free
Desktop Accessibilty Working Group, of integrating the GNU Accessibility
Framework (aka 'GNOME Accessibility Project') with KDE.  GAP comprises
two layers of API, the "ATK" is an in-process API for accessibility
within applications, and AT-SPI is the "service provider interface"
which is application and toolkit-neutral.  Presumably one of two
approaches would be used:

* ATK support could be integrated into KDE/Qt, and the bridging/IPC
technologies in AT-SPI's current implementation could be reused.  This
is by far the easiest approach, and gives the best code reuse, but would
require that KDE link to glib and libatk (but no other 'GNOME'
libraries).  (glib and atk are LGPL)

* alternatively, KDE could use a QT/KDE-specific APIs internally and
bridge them to AT-SPI (in the way that Java applications bridge their
'Java Accessibility API' to AT-SPI in our current code).  This is a lot
more work, and less code reuse, but moves the dependency from atk+glib
to an IDL layer.  Again, it would be best to implement this IDL in
CORBA, for complete binary compatibility, but a comparable IPC
technology could be substituted at the expense of writing yet another
bridge from this layer to CORBA.

In any case, provision of a truly object-oriented, toolkit-neutral IPC
is required to export a suitable accessibility service for use by a wide
range of assistive technologies (such as screenreaders, onscreen
adaptive keyboards, etc.)  The advantage of going with the existing GAP
architecture is that 'alpha' versions of such assistive technologies,
and integration with Java, Mozilla, and the OpenOffice software suite is
already available.

best regards,

Bill Haneman
 
> Gunnar Schmidt
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list