[Kde-accessibility] kttsd and KSayIt etc...

Bill Haneman Bill.Haneman at Sun.COM
Wed Feb 4 15:03:54 CET 2004


What we did with gnome-speech is abstract a service that allows clients 
to do basic things like choose speakers/voices, say text, and interrupt 
speech.  Our service uses CORBA as the IPC mechanism but clearly that's 
an implementation detail.  For something as simple as the current speech 
APIs, DCOP or DBUS should be sufficient.

Note that a sockets approach needs to be re-enterant since you don't 
want to impose synchronous behavior on the clients.

In either case we're talking about a service (gnome-speech or kttsd) 
that's "transparent" (i.e. invisible) to the user. 

Typical requirements would include the ability to share cleanly between 
clients, not hogging or blocking the audio device, and the ability for 
clients to specify/use different 'voices'.  A single global collection 
of settings for kttsd may not be a good idea for this reason, as 
different clients may have their own needs or configurations.  If a 
single 'default' voice configuration is desired for programming 
convenience or cross-client consistency, that may be reasonable, but 
such a default should not be the only voice available to clients.

regards

Bill

Pupeno wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi, I'm the original developer of KTTSD, no longer mantaining the project but 
>I think my knowledge of it might come usefull now.
>
>On Sunday 01 February 2004 17:45, Robert Vogl wrote:
>  
>
>>1.) kttsd
>>
>>In this context kttsd should be designed as a pure server-daemon that
>>offers a well defined interface to its clients e.g. via DCOP or
>>IPC-Sockets. The interface should receive the text to speak and implements
>>elementary functions like 'start', 'stop', 'pause'. All lowlevel
>>functionality like queue-handling, prioritization, sentence segmentation or
>>whatever should be addressed to the daemon to keep the clients as simple as
>>possible. As a daemon kttsd is completely invisible for the user (like KDEs
>>sound server artsd), i.e. it doesn't require any GUI functionality. The
>>configuration of kttsd should be performed via a KDE Controllcenter Module
>>(KCM) and a set of plugins for the several existing TTS systems. The KCM
>>may offer a checkbox of type: "Start kttsd on KDE startup".
>>    
>>
>All that, excep asyncronus stoppping is already implemented and working, 
>exactly as you describe it (I'm proud that I reached the same design as the 
>mind of another developer :)
>
>  
>
>>The runtime control of kttsd may be performed by a stand-alone tool named
>>'kttscontrol' (in the style of artscontrol). GUI and functionality of that
>>tool is essentially the dialog that pops up if "restore" of the todays
>>system tray of kttsd was clicked.
>>    
>>
>This is not implemented but is a good idea, if there's something to control at 
>all.
>
>  
>
>>Because a server alone makes no sense we need a bunch of clients. KSayIt
>>easily could be reimplemented as a client for the above described kttsd.
>>It's located in the system tray to speak the content of the clipboard by a
>>single mouse click and can also offer the simple editor view like today.
>>The setup dialog is no longer required as well as the speaker stuff since
>>both is delegated to kttsd and its KCM.
>>    
>>
>I agree, good luck with your developing! :)
>- -- 
>Pupeno: pupeno at pupeno.com
>http://www.pupeno.com
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3 (GNU/Linux)
>
>iD8DBQFAIBODtCepaMf3unIRAg4KAJ9IeBKf9Gq5HJFjXFSZ83jBqoBEDACfdIdU
>LWYr76WWR8VWHR0066Cty2s=
>=JHY+
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>kde-accessibility mailing list
>kde-accessibility at kde.org
>https://mail.kde.org/mailman/listinfo/kde-accessibility
>  
>




More information about the kde-accessibility mailing list