[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Proklam structure (was Merkury)
From:       Pupeno <pupeno () pupeno ! com>
Date:       2002-07-19 22:25:37
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I won't be able to use the name Mercury since Compaq/HP is using Mercury for a
project to do 'something' with wireless PDAs, audio and video streeming, etc,
etc.
Well, no it's called Proklam unless someone comes with a better name. The
interface class will be still called KSpeech.
So, the project is still divided in three parts.

Proklam: the dcop service.
This is a dcop service that can be run on demand. It'll be in kdenonbeta by
know and anywhere else when it comes stable enough (3.3 maybe).
It will be plug in based so it will load one and only one plug in which will
provide some functions like init() which will init the synth and sayText()
that will say a text. So, Proklam won't depend on anything and can be
compiled without any speech system, but of course, won't do anything. Then,
plugins per speech system (Festival, FreeTTS, ViaVoice) will be made, this
plug ins will be linked against the libraries that may or may not be in the
system.

KSpeech KCModule.
This is the KControl module that will allow the user to select wich system he
wants to use (Festival, FreeTTS, etc, etc) and acording to the system chosen,
a diferent set of options will be shown acording to the TTS (very reach in a
case like Festival and very poor in a case like FreeTTS), this mean that
people using Festival would need almost no hand tuning of the system will
FreeTTS will need a lot.

Note: the plug in will be in charge of reading the configuration generated by
this module and configure the synth dynamically, should the 'configuration
widget' of the specific speech system be provided as a plug in in the same
way the interface ? so, if someones wants to add a new speech system, the
source code of Proklam doesn't have to touched but the two plug ins will be
needed, one for the procesing and one for the configuration. Is this ok ? any
comment will be very usefull.

KSpeech class (the api for you, other developers willing to use my wonderfull
system ;)
There will be a function:
KSpeech::sayText(QString, type);
Where QString will be the text to be say and type could be: text, message or
warning.
If there's a warning, the warning will be told first, then the messages, and
then the texts.
The texts will be borken into parts, sentences and paragraphs which will be
feeded one by one to the synths, the idea of this is that if you have a long
text that could make the system speek for an hour, the system won't be stuck.
Between sentences, a check for warnings will be hold, if there's a warning it
will told, between paragraphs, a check for erros and then for messages will
happen, if any found, it will be told.
Other functions like:
KSpeech::pause(), KSpeech::cancel(), KSpeech::backSent(int sent),
KSpeech::backPar(int par), KSpeech::forwardSent(int sent),
KSpeech::forwardPar(int par), will be provided to navigate long texts (for
example, a plug in for kate and a similar one for knoqueror could read texts
and provide short cuts to make navegability thru the text very easy).
Am I missing anything ? please, any comments, constructive critisism will be
very welcome.
Thank you.
- --
Pupeno: pupeno@pupeno.com
http://www.pupeno.com
PS: Could you spot me texts and/or (simple) source code on plug ins ? I've 
read about making plug ins, it's preaty easy, but I didn't read about loading 
plug ins because I didn't find anythihg.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9OJHjLr8z5XzmSDQRAka3AJ9OlGHW3+W6wt+zRbF9MwOUwXgqFACgqP/Y
mdXiwqbqfUoLaXhPqmvhPA4=
=4575
-----END PGP SIGNATURE-----


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]