[Kde-accessibility] Proklam and KMouth

[Olaf Jan Schmidt]

Hi Bill, hi Pupeno, hi Peter,

Bill, thank you very much for your additional information about=20
gnome-speech and GAP. From reading the GAP website and the archives of=20
kde-accesibility, I understand that there have already been a lot of=20
thoughts how to make GAP toolkit independent. I appreciate this very=20
much.

The problem is just that both Pupeno, Gunnar and me are really new to KDE=
=20
programming. We do not know which concepts have been discussed before,=20
and we do not have any experience with accessibility programming.

We do all of this as a fun project and we have limited time and knowledge=
=20
of all this. We do not have the time and resources to make KDE completely=
=20
GAP compatible, all we can do is make sure that some partial support for=20
GAP opens the door for further development.

KMouth is a really new and small program. At the moment, we support=20
neither Proklam nor gnome-speech, and of course we would prefer to only=20
have to support one API, which is a standard for all Linux.

We are in a difficult situation at the moment. We would like to encourage=
=20
Pupeno by supporting his Proklam project, as he is one of too few KDE=20
developers dealing with accessibility issues. But we also do not want to=20
to brake an evolving standard for accessibility technology on Linux.

Peter, I am very thankful that you pointed us to this problem, for it=20
probably would have been very difficult to change the road later.

Pupeno, since you already did a lot of work on Proklam, it is very=20
important to me that your work can be used by as many people and=20
applications as possible. You once wrote that you have a dream that=20
Proklam can be used not only by KDE programs but also by all kinds of=20
other Linux programs. I understand that this can be achieved by making=20
Proklam a GAP speech backend. This would make sure that we do not brake=20
any evolving accessibility standard, and all Linux programs (including=20
GNOME ones) could make use of your graphically configured tts system.

There are basically three options to achive it:
1. Use the GNU Accessibility Framework for all communication between=20
Proklam itself and Proklam clients. This would require heavy changes to=20
Proklam, but it would be the start of a wonderful cooperation between KDE=
=20
and GNOME accessibility technologies. As KDE goes beyond Linux (e.g. BSD,=
=20
Mac OS X, Solaris, etc.), it is an important question whether the GNU=20
Accessibility Framework is Linux-specific.

2. If the first option is not possible or too much work for the beginning=
,=20
we could write an extended Proklam-support-library that also tests for=20
GAP support. If GAP technology is installed, then gnome-speech is used,=20
otherwise only Proklam can be used. This library could be used as a=20
general Proklam-GAP client bridge.

If Pupeno makes sure that there is a second bridge for Proklam acting as =
a=20
GAP speech backend, then the whole communication between Proklam and the=20
KDE programs could be done via the GNU Accessibility IPC, if GAP=20
technology is installed.

Both approacheas also only make sense if all functions of the Proklam=20
protocol are available in the GAP IPC:
a) Can a program specify the language of a spoken message?
b) Is it possible to differentiate between short error alerts, short=20
messages and long texts? (Long texts are parsed by Proklam and broken=20
into sentences. Between two sentences, important error alerts and=20
messages can be spoken.)

3. If both is not possible, then we could use an architechture similar to=
=20
the second approach, except that both bridges are part of Proklam itself.=
=20
One bridge would allow Proklam to use gnome-speech, and the other would=20
make Proklam a gnome-speech backend.

Which of these options is the best?
This also depends on which approach is used for the other parts of the=20
GAP, as Bill has explained:

> * 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 woul=
d
> 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.

Note that even if my third approach is neccessary for Proklam, both of=20
Bill's approaches be used for AT-SPI.

It might be neccessary to discuss this issue with some KDE core=20
developers, so that we do not start implementing something which later=20
shows to be the wrong approach. (This mainly refers top my first=20
approach.)

Pupeno, you must be frustrated to see so many questions to the details of=
=20
the Proklam project, but remember that nothing of your work is lost by=20
writing a bridge that allows Proklam to function as a GAP speech backend.=
=20
I think that even if supporting the GAP is the togher way for now, it=20
could be the beginning of a wonderful cooperation of all Linux=20
accessibility projects. (Pupeno, think of the nice headlines! I will make=
=20
sure of those.)

KMouth will definately support both gnome-speech and Proklam. We would of=
=20
course prefer a gereral solution within Proklam, upon which only Pupeno=20
can decide. In the worst case, KMouth would need its own GAP support=20
library, which can be used to be a general Proklam-GAP client for other=20
programs as well.
But I hope that Pupeno will find a way to cooperate with the GNU=20
Accessibility Framework without doing too many changes.

Olaf.

--=20
Meine Internetseiten:
http://www.GebetGenerator.de, http://www.amen-online.de