Re: [Kde-accessibility] Proklam and KMouth

[Olaf Jan Schmidt <olaf amen-online de>]

Hi Bill, hi Pupeno, hi Peter,

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

The problem is just that both Pupeno, Gunnar and me are really new to KDE 
programming. We do not know which concepts have been discussed before, 
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 
of all this. We do not have the time and resources to make KDE completely 
GAP compatible, all we can do is make sure that some partial support for 
GAP opens the door for further development.

KMouth is a really new and small program. At the moment, we support 
neither Proklam nor gnome-speech, and of course we would prefer to only 
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 
Pupeno by supporting his Proklam project, as he is one of too few KDE 
developers dealing with accessibility issues. But we also do not want to 
to brake an evolving standard for accessibility technology on Linux.

Peter, I am very thankful that you pointed us to this problem, for it 
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 
important to me that your work can be used by as many people and 
applications as possible. You once wrote that you have a dream that 
Proklam can be used not only by KDE programs but also by all kinds of 
other Linux programs. I understand that this can be achieved by making 
Proklam a GAP speech backend. This would make sure that we do not brake 
any evolving accessibility standard, and all Linux programs (including 
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 
Proklam itself and Proklam clients. This would require heavy changes to 
Proklam, but it would be the start of a wonderful cooperation between KDE 
and GNOME accessibility technologies. As KDE goes beyond Linux (e.g. BSD, 
Mac OS X, Solaris, etc.), it is an important question whether the GNU 
Accessibility Framework is Linux-specific.

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

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

Both approacheas also only make sense if all functions of the Proklam 
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 
messages and long texts? (Long texts are parsed by Proklam and broken 
into sentences. Between two sentences, important error alerts and 
messages can be spoken.)

3. If both is not possible, then we could use an architechture similar to 
the second approach, except that both bridges are part of Proklam itself. 
One bridge would allow Proklam to use gnome-speech, and the other would 
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 
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 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.

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

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

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

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

Olaf.

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