[orca-list] Sluggishness in Orca

[Luke Yelavich]

On Fri, Nov 02, 2018 at 07:50:45AM AEDT, Didier Spaier wrote:
> Hello,
> 
> On 01/11/2018 21:22, Luke Yelavich wrote:
> > I have covered this before from a speech-dispatcher point of view. I've 
> > even documented my thoughts on it in the TODO file. If someone wants to do 
> > the work, a rough outline is there.
> 
> Thanks for the heads-up, Luke.
> 
> The first character line #70 should be a closing curly bracket, not a square 
> bracket ;)

A typo, but not important for documentation like that I think. Feel free to fix 
it. :)

> More seriously, this leads to a few questions:
> 1) Why make these settings depend on Migration to GSettings?

It doesn't have to depend on gsettings, but some sort of settings system would 
need to be used that can be written to or read from easily. I had started 
working on moving speech dispatcher to GSettings, hense why in the TODO file, I 
noted that it depended on the GSettings work.

A user of a speech dispatcher client may want to set a setting for a specific 
synthesizer for that client. Using server side settings storage would allow the 
speech-dispatcher server to store that setting for that client, without the 
client itself having to be concerned about storing specific settings for a 
specific synthesizer.

> This would need that all systems that use speech-dispatcher implement 
> gsettings, maybe it's a too heavy requirement?

No, the only components that need concern themselves with gsettings in this 
context are the server, and the synthesizer module. Clients can use whatever 
they wish.

> 2) Creating a per synthesizer API would need to adapt the clients like Orca 
> to the API of each synthesizer if I understand well.

No. The API would be such that a client could get a list of settings per 
synthesizer, and present them to the user if it wishes, and change any setting 
if desired also.

To be clear, Orca would not need to know a thing about ESpeak's variants, 
because the API would specify a textual string to describe the setting. Orca 
need only provide the UI to the user to allow the user to change the voice 
variant of espeak. Orca then need not even worry about storing that setting, 
because the server, via gsettings, or whatever else is used, would store the 
setting for the client.

> Wouldn't it be less work for the client's developers to just adapt the client 
> once to a change in the current API?

Yes, extend the client to use the synth specific settings api, and any settings 
that get added to any module in the future will be seen by clients using the 
synth specific settings API.

Luke