[Kde-accessibility] Proklam and KMouth

[Pupeno]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 23 September 2002 15:57, Bill Haneman wrote:
> It's not as crazy as it may sound.  If the two have interfaces that map
> onto one another, they can interoperate freely, which was my point.
> Though of course you wouldn't use the two "plugins" in a circular
> fashion, if the services interoperated fully then all Proklam clients
> could access all gnome-speech engines, and all gnome-speech clients
> could access all the Proklam drivers.  That would be the goal.

To achive this we should work together on the architecture of both projects=
=2E..=20
do you have any idea of how to do it ? I'll subscribe to gnome mailing list=
s=20
to work with the gnome developers, which should I go to ?

> What we found in discussions with assistive technology engineers was
> that good accessibility requires some fairly advanced features, or at
> least better than lowest-common-denominator.  But by doing all the
> complexity in the front-end, as you suggest, you lost the ability to use
> powerful TTS backend features, and you probably increase latency (which
> is a big issue for accessibility).
>
> On the other hand if your API is rich and full -featured, you can choose
> to expose advanced features from the TTS driver when they are available,
> and otherwise wrap/emulate them in the frontend, as you suggest for
> stopping speech.
Yes, I understand... I think I'll make a base from where to construct the=20
rest, as more feature rich TTS appear I'll see how to implement and emulate=
=20
that features.

> I think the big difference here is that you have decided to fix both the
> front and back ends of your architecture, which is very limiting if you
> are trying to make flexible plugins.  The gnome-speech architecture is
> not really suitable as a lowest-common-denominator back-end, it is a
> rich-featured "front end".
>
> In gnome-speech we do not have a single back-end API, we use the APIs
> available to us from the TTS engines.  If you did likewise with Proklam
> you would be able to access the extended features you mention much more
> readily.  My suggestion is that the front ends of the two architectures
> should be made as similar as possible. for a number of reasons.
Are you saying that gnome-speech comunicates with the TTS directly ?
I use a plug in based architecture... I have the core of Proklam and then p=
lug=20
ins that are the interfaces from Proklam to the TTS. I chosed to do it this=
=20
way because this way, Proklam doesn't depend in any TTS, in fact, you can=20
compile Proklam without any TTS, the plug ins are the parts that depends in=
=20
the libraries, and Proklam uses standard methos to look for the available=20
plug ins.

> gnome-speech does not have a single back-end API, for the reasons you
> allude to yourself.  gnome-speech could be a plugin for Proklam, but
> only if Proklam had a more flexible back-end that allowed for both
> simple and complex TTS drivers would you be able to use gnome-speech's
> advanced features effectively.
Ok, I'll have that in mind in the redisign of Proklam.
=2D --=20
Pupeno: pupeno@pupeno.com
http://www.pupeno.com
=2D ---
Help the hungry children of Argentina,=20
please go to (and make it your homepage):
http://www.porloschicos.com/servlet/PorLosChicos?comando=3Ddonar
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9j3htLr8z5XzmSDQRAjy5AJ97L06xMjrw6x8GQjit9OaRL9+WjACfSBsT
qRJfJmQrN8Gz/iOytJ60GVI=3D
=3DhlsQ
=2D----END PGP SIGNATURE-----