[Accessibility] Synthesizer choice api

verum nocte vernocte at gmail.com
Sat Feb 14 11:16:55 CET 2015

I am no expert at field so my reply shouldn't count for much (it is just
that noone else replied so far). I believe that general rule of a thumb in
this situations is to send as much data as needed and than deal with it
accordingly when it is needed. It is generally easier to ignore unneeded
field than get data you don't have on your disposal.


On Wed, Feb 11, 2015 at 2:19 AM, Jeremy Whiting <jpwhiting at kde.org> wrote:

> Hey all,
> Today I took another look at qtexttospeech_unix.cpp and realized we are
> only exposing the default speech dispatcher output module's voices to the
> api. I think either one of two things needs to happen. Which sounds more
> usable?
> 1. When the backend starts up it not only gets the output modules and
> create a QVoice for each one. This would require QVoice to have additional
> data about which output module it is using, but wouldn't require any api to
> switch output modules, just switch voices and it would switch the output
> module for you.
> 2. Add api to QTextToSpeech to get and set the synthesizer. Whenever the
> synthesizer is set the list of QVoice objects (availableVoices) will likely
> change, but QVoice itself wouldn't need to contain which synthesizer the
> voice is for.
> I'm a bit torn myself, I think 1 is a better fit for the unix backend, but
> it's probably not as usable/meaningful on other platforms. Though maybe all
> platforms QVoice will need to have custom data associated with it, so we
> could add a QVariant or something to QVoice to hold it.
> thoughts?
> thanks,
> Jeremy
> _______________________________________________
> Accessibility mailing list
> Accessibility at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/accessibility
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/accessibility/attachments/20150214/70febc2f/attachment.html>

More information about the Accessibility mailing list