garycramblitt at comcast.net
Sat Jul 15 19:27:28 BST 2006
On Wednesday 12 July 2006 09:20, Thomas Zander wrote:
> > 2. Sender Names. If you need to know a message's sender, this is
> > presently rather painful, requiring hand-coding of adaptors. Knowing
> > who you are talking to is fundamental.
> Actually; I implemented various similar frameworks; including one
> grid-computing solution, and I never ever had the need to find the name
> of the service connecting to me.
> This is only needed when encrypting a connection and that implies a
> handshake which will do something like this anyway.
Use Case "Joseph"
Joseph is a 50 year old consultant. He frequently reads long technical
articles on the web and chats in IRC and IM with other consultants and
customers. Joseph's eyesight has diminished with age, so he prefers to have
his computer speak text whenever possible. He likes to click the "Speak"
button in Konqueror to have the computer read out long-ish articles, but he
also follows along in the article in case there are TTS errors,
abbreviations, or diagrams to look at. He also has Konversation and Kopete
set up to speak incoming messages he is interested in. This both alerts him
that he needs to switch to Konvi or Kopete and also provides less eye strain.
While speaking a long article in Konqueror, and a client messages him in
Kopete, he needs to be able to pause the Konqueror TTS, while still
permitting TTS in Kopete to continue.
The usability folks recently did some testing of KTTS in Berlin (thanks el,
Olaf, and others!) and two issues emerged. 1. Users expect to be able to
control speech from the application where the speech originates, so if speech
is started in Konqueror by clicking a Speak button, they expect a Pause or
Stop button there as well. 2. Joseph can do what he wants via the current
KttsMgr interface, but the dialog is too complex and confusing. Currently,
Joseph must click the Pause button in KttsMgr, then move his Konqueror speech
job downwards in the job list. Under the current architecture, a paused job
blocks all other jobs "below" it, regardless of which applications they come
I agree with both of these assessments, so one of the things I'm trying to do
with KTTS in KDE4 is improve the API so that operations are more intuitive
for users while keeping the API simple for application developers. To
accomplish this, KTTSD must know from which applications the service requests
are coming. An application initiates one or more speech jobs via
say(QString text) and can pause all of its jobs by calling pause(). This
does not block any other application's speech. (Another way this can be
accomplished is to require applications to keep track of the jobNum of every
job they initiate and make them specify the jobNum when they call pause.
However, this also requires the application to track signals from KTTSD when
jobs are finished. IMHO, this is overly burdensome on application
developers. Besides, this is what KTTSD is for.)
Use Case "Mary"
Mary is a 30-year old mother and an experienced KDE user. She makes extensive
use of TTS, partly because its just fun, but mostly because it permits her to
multitask. She usually has five or six applications running simultaneously,
including Konqi, Amarok (with the Disc Jockey TTS plugin enabled), Konvi,
Kopete, KOffice, KPDF, and KMail. She likes to be able to listen to
conversations in Konvi via TTS, while simultaneously reading mail, web pages,
PDFS, etc. Mary has a 9 month old baby (Tim) who keeps her pretty busy, so
when she finds the time to sit down at her computer, every second is
valuable. Whenever Tim demands her attention she needs to be able to pause
all TTS output quickly and easily. A Mute button doesn't cut it, because
then she misses out on important information.
In this case, Mary needs a single Pause button that pauses all speech of *all*
TTS applications. The approach I'm taking is to permit an application to
designate itself as a "TTS System Manager" application. When such an
application calls pause(), it pauses TTS output of all applications.
(KttsMgr will take on this role as TTS System Manager, but the API will
permit any application to act as TTS System Manager). The essential point
here is that once again, KTTSD needs to know the application that is
Note that neither of these use cases involve authentication or security.
Gary Cramblitt (aka PhantomsDad)
KDE Text-to-Speech Maintainer
More information about the kde-core-devel