[Kde-accessibility] KDE Speech API Draft 2 and new KTTSD

[Olaf Jan Schmidt]

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

[Gary Cramblitt, Sonntag, 16. Mai 2004 02:49]
> I have posted for comment Draft 2 of the KDE Text-to-speech API

Sorry for my delay in responding.

It is good that you keep API compatibility for SayMessage, as this is the 
only function that is (optionally) used by a released application 
(KMouth).

There are mainly three types of usage for speech synthesis:

1. Speaking and navigationg through whole texts (can be interrupted by 
messages and screen reader speech)
2. Speaking single messages (can be interrupted by screen reader speech)
3. A screen-reader reading out whatever happens on the screen (can be cut 
off by new screen reader speech)

The suggested API is very feature-rich for the first two uses, but the 
third use is not covered. I must admit that I don't know much about 
screen-readers, so I cannot really comment on this, but I am wondering 
whether it would make sense to simplify the API for the first two uses as 
much as possible in order to have it still manageable if we later add 
functionality for screen-readers as well.

Keeping the API simply was also the reason why I was wondering whether 
only one application should be allowed to read out texts, and whether all 
navigation should be done in this application itself. The parsing of 
texts into paragraphs and sentences would be removed from the API. This 
would also allow to write clients that read out html or xml with speech 
mark-up rather than plain text. 

Kttsd would then be sent a list of single sentences, and allow to jump to 
textpart number n ("markers"):

virtual uint kspeech::newText (const QString &talker=NULL)
(returns job number)

virtual uint kspeech::addToText (const QString &textpart);
(returns id)

virtual void kspeech::jumpTo (uint job, uint id);


Another thing I was always wondering about was if it is really necessary 
to have two seperate queues for messages and warnings. Maybe the code 
would be smaller and easier to maintain with either having simply one 
queue, or having a priority flag instead. But I leave this to your 
decision as a maintainer, I don't really care much about this.

Olaf

- -- 
Olaf Jan Schmidt, KDE Accessibility Project
KDEAP co-maintainer, maintainer of http://accessibility.kde.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAkCs2d8ACgkQoLYC8AehV8dh5ACdHKgVDZZgcdhEp3bro89RAtmF
3kIAmwbQ6adNUt9yXV/2x4gIJJENLaYc
=SHwD
-----END PGP SIGNATURE-----