[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[orca-list] Sluggishness in Orca
From: |
Luke Yelavich |
Subject: |
[orca-list] Sluggishness in Orca |
Date: |
Fri, 2 Nov 2018 08:30:29 +1100 |
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