DBus/QtDBus Concerns

[Gary Cramblitt]

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 
from.

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 
requesting service.

Note that neither of these use cases involve authentication or security.

-- 
Gary Cramblitt (aka PhantomsDad)
KDE Text-to-Speech Maintainer
http://accessibility.kde.org/developer/kttsd/index.php