[Kde-accessibility] Proklam and KMouth

[Gunnar Schmi Dt]

Hello,

> [...]
> > Which kinds of DCOP messages do currently exist?
>
> Well, the dcop speeking functions are three.
> sayWarning, sayMessage, and sayText.
> Warnings and Messages are functionallity the same, they only vary in th=
e
> importance of the message. Warnings are spoken first. Texts are special=
 and
> is for long texts. [...]
> The messages to navigate thru texts are added... like
> a CD player, you can go sentence by sentence or pargraph by paragraph t=
o
> the begining or to the end. Only one text can be in the system at a tim=
e,
> any amount of warning and messages can be. Warning and messages can be
> removed (they're assigned a unique ID to do this). [...]
>
I think the phrases that are spoken via KMouth should be classified as=20
messages? I do not need to navigate through them, but a feature to stop=20
speaking a phrase would be nice. (Is it possible that KMouth gets informe=
d=20
when Proklam finishes speaking a message?)

> [...]
> > 4th idea: Make it possible to load several plug-ins, and implement a
> > parameter forwarding mechanism. When the program asks for special
> > parameters ("language" =3D "en" and "sex" =3D "female"), then Proklam=
 calls a
> > parameter function in the default plugin. If the function returns wit=
h
> > "false", then the next plugin is tried. If none of the active plugin =
is
> > found, then the default configuration is used.
> [...]
> My idea is this... as you say, load more than one plug in at a time. In=
 the
> KControl module, you'll chose to add a language... so, you add the lang=
uage
> English and a tab or something like that for English is added, then, in=
side
> that tab, you chose which plug in you want and which voice you want
> (Festival for example, doesn't trully separate languages, but voices, y=
ou
> could end up defining an spanish voice for a english), then if you add
> Spanish, another tab for Spanish is added.
> [...]
With KMouth in mind I could work with both ideas. However, I need a list =
of=20
languages that are supported by Proklam (I assume that Proklam has a func=
tion=20
that can be used to enquire this list). The former idea needs to be exten=
ded=20
for that (each plug in needs to contain a function that returns a list of=
=20
languages).=20

The formar idea is more work to implement:
-There needs to be a larger interface between Proklam and the plug ins.
-Proklam needs to contain some more complex code in order to determine wh=
ich=20
plug in is used.
-Each multilingual plug in needs to have a multilingual configuration, wh=
ich=20
is more complex both to implement and to use than a single-lingual=20
configuration (selecting multiple voices for multiple languages for examp=
le).

As both ideas contain the fact that Proklam can load multiple plug ins at=
 the=20
same time, I do not see why we need to implement this overhead. Therefore=
 I=20
would prefer the latter idea.

Gunnar Schmi Dt