<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hemant,<br>
<br>
The point I was trying to make was that the Sugar API itself could have
removed the burden of setting these options from the developer. An
Activity, with just one line of code, could have set his speech client
to the default values. An Activity could also, using the API, find out
what the default values are without having to look at speechd.conf. Or
the Sugar Activity base class could automatically start up a speech
client and give the Activity developer simple methods to use it in his
application, or even automatically speech enable any Activity so that
for instance the contents of the control with the focus could be
spoken, or whatever it is that screen readers for the blind do. I
understood that the Sugar developers wanted to provide text to speech
support to all Activities, even those written before TTS was
available. To do that you would have to change the Sugar base classes,
etc. anyway.<br>
<br>
I don't see it as having redundant configuration. I see it as having
one configuration specifically tailored for what Sugar needs to do and
to be and another which is for all practical purposes completely
ignored.<br>
<br>
Just one man's opinion.<br>
<br>
James Simmons<br>
<br>
<br>
Hemant Goyal wrote:<br>
<blockquote
cite="mid8c53493a0807180855j1d58f9dcp551d418a6bec1deb@mail.gmail.com"
type="cite">
<div dir="ltr">Hi,<br>
<br>
Thanks all for your inputs :)<br>
<br>
I managed to make speech-dispatcher as non-root using /tmp/speechd.pid
and relocating the log files that were being written to
/home/olpc/.speechd/. Since I started speech-dispatcher through the
user olpc the log files need to be in a ~/ of olpc.<br>
<br>
@James:<br>
<blockquote
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"
class="gmail_quote">I have some experience using speech-dispatcher and
it seems to me that the XO really doesn't need to run speech-dispatcher
any differently than any other computer does (other than getting rid of
unnecessary dependencies of course). My understanding of what you want
to do is that you want your contro,l panel to change the default
settings in speechd.conf and restart speech-dispatcher so that all
Activities that use speech will have these new default values to work
with.</blockquote>
<div><br>
In addition to what you have suggested, we want that a user be able to
select speech synthesis settings in sugar-control-panel, and that those
settings transparently get applied to all other client connections
without the knowledge of the developer in the background when a
connection is established.<br>
<br>
</div>
<blockquote
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"
class="gmail_quote">To my mind doing this (if I understand you
correctly) is like burning down your house to cook a pig.
Speech-dispatcher lets you override pretty much anything in
speechd.conf. Since that is true, isn't the real problem how to give
Sugar Activities a way to get these values set up for them using some
data store maintained by your control panel? The data store doesn't
have to be speechd.conf. It could be any file that can be updated by
your control panel and read by other Activities. The Sugar API could
have a method that takes the speechd client as a parameter and applies
all the system-wide defaults that you are maintaining to it. After
that the Activity could make changes on its own and save the values as
meta information or whatever.</blockquote>
<div><br>
Right, we did consider this approach but :<br>
<ol>
<li>maintaining 2 copies of a similar configuration was not an
elegant design option</li>
<li>we do not want the developer to make any effort whatsoever when
they connect with speech-dispatcher to read/write/get and apply these
settings every time they connect to speechd. In short this will lead to
redundancy or replication of the code throughout activities, which will
just be getting the settings and then applying them for their client
connection.</li>
</ol>
On the other hand, with the present approach of modifying speechd.conf
the activity developer will not be required to write code to read these
settings from the datastore and apply them for his/her own connection
with speechd, instead the sugar defaults will be read and applied by
speech-dispatcher themselves.<br>
<br>
Please let me know in case I have misinterpreted the point made by you.<br>
<br>
</div>
<blockquote
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"
class="gmail_quote">In any case, speechd does not have to run with
dangerous permissions and Sugar Activities should get the benefit of
your control panel with minimal work.</blockquote>
<div><br>
Right, I have fixed this in my RPM package. I will soon be releasing
the newest RPM which wont have any additional dependencies and which
can be started by olpc user on the laptop.<br>
<br>
Thanks again for all the inputs.<br>
<br>
Cheers!<br>
Hemant<br>
</div>
<div><br>
</div>
</div>
</blockquote>
<br>
</body>
</html>