Hemant,
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.
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.
Just one man's opinion.
James Simmons
Hemant Goyal wrote:
Hi,
Thanks all for your inputs :)
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.
@James:
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.
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.
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.
Right, we did consider this approach but :
1. maintaining 2 copies of a similar configuration was not an
elegant design option
2. 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.
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.
Please let me know in case I have misinterpreted the point made by you.
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.
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.
Thanks again for all the inputs.
Cheers!
Hemant
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
