[Kde-accessibility] Proklam and KMouth

[Pupeno]

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

On Monday 23 September 2002 14:55, Bill Haneman wrote:
> Olaf and Pupeno:
>
> Thanks very much for all your time, and for looking at a project that at
> first may seem to be very independent of your needs.  I agree that there
> seems to be a great opportunity to cooperate here, and I'd like to do
> all that I can to help do that.
You're welcome, that's why we're here.

> I will reply to some of your other points in detail later (for today I
> must log off :-).
Ok... there's always tomorrow. :)

> But in short, I think that there are several different ways that we can
> ensure that our projects work together and that the maximum flexibility
> and power is offered to users on KDE, GNOME, and other platforms as
> well.
>
> Certainly Proklam could use a gnome-speech plugin as a backend, and
> gnome-speech could also use or offer a Proklam backend, if perhaps
> Proklam were to support some devices which gnome-speech does not.  The
I don't want to see what happens if Proklam is configured as a gnome-speech
backend AND gnome-speech is configured as a Proklam backend.

> key to making either of these solutions work easily is to agree on a
> common general API, which is why IDL is a nice starting point.  For us
> we go from there to generate CORBA bindings, but or course IDL can be
> used to make Java bindings or be used as the basis for other IPC
> mechanisms.  In principle IDL is implementation-dependent, it's only
> because CORBA uses it extensively that it is associated with CORBA, but
> it isn't exclusive to CORBA.
As I said in another mail... I expect as little as posible from the TTS,
that's why Proklam does a lot of parsing and preprocessing. I think this wi=
ll
allow me to use as many TTSs as posible.
I know this won't allow me to use the extended features of feature rich
TTSs... I may think of some workarroud solution for some features, like the
ability to stop on demand... when a stop message is recived by Proklam... it
should mark the text to be stoped and run a stop function for the plug in...
it may stop in the moment or just ignore it. It also depends if the say
function is blocking or not.

> So if our APIs are close enough, the possibilities for how the two
> architectures plug together are much more flexible, and much less work
> is involved in writing either kind of plugin.  This means of course that
> we need to try to find IDL that meets the needs that we've both
> identified, i.e we should make sure we haven't "left anything out" of
> our IDL which would be important to Proklam and vice-versa.
As gnome-speech would be a plug in from Proklam, Proklam's interface doesn't
have to be similar to gnome-speech's but Proklam's plug in interface should
be similart to gnome-speechs's and I think the best would happen to
gnome-speech (aren't the interfaces from the aplication and to the TTS very
diferent in gnome-speech ? well, in Proklam they're, from the application,
there's a rich interface with lot's of features and capabilities and more a=
re
to be developed, and to the TTS there's a simple interface so any TTS could
be used).
I'll take a look at the IDL and I'll write a document that I'll update to t=
he
CVS server (public available on webcvs.kde.org).
Thank you.
=2D --
Pupeno: pupeno@pupeno.com
http://www.pupeno.com
=2D ---
Help the hungry children of Argentina,
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)

iD8DBQE9j29XLr8z5XzmSDQRAvFkAJ4965Q3Z+uJnC5+9kzAM+V8ml1onwCg3bRb
PQTEdHrIFN+5/tA1gps0w6c=3D
=3D0llV
=2D----END PGP SIGNATURE-----