[Accessibility] qtspeech status

[Jeremy Whiting]

Frederik,

Ok, from a quick look through the wiki page it looks like we have the
following requirements:

The api needs a method to set the language, windows/mac/linux have api
to get a language list, but android doesn't.
The api needs a way to set the voice parameters, this includes but
isn't limited to gender, speed, pitch, volume, id (module on linux?).

In some (all?) platforms the language is another voice parameter also.
I see this working one of two ways (jovie had/has both, but I think we
should pick one and stick to it)
1. The api has a voice type (QTextToSpeechVoice) and the api has
get/set methods of these objects which contain all the other
parameters.
2. The api has getters/setters for all properties and the
QTextToSpeechVoice type is removed, so setRate, setPitch, setVolume,
setGender, setId, etc.

Either way we should have appropriate qWarning messages on each
platform for the voice parameters that aren't supported on that
platform. Also, I'm leaning towards solution 1 since that way we could
extend the api easily later by adding properties to the
QTextToSpeechVoice class itself if needed and it more closely matches
the backends from what I've seen.

Also, I had imagined that rather than having spd default configuration
api in qtspeech itself that we could/would have jovie become a kcm to
wrap spd-conf itself. Maybe another tool could be added like qtconfig
too, not sure, for those not wanting for whatever reason to run a kcm
or spd-conf itself.

thoughts?
Jeremy

On Mon, Oct 13, 2014 at 2:41 AM, Frederik Gladhorn <gladhorn at kde.org> wrote:
> On Friday, September 26, 2014 06:00:47 PM Jeremy Whiting wrote:
>> Hello list,
>>
>> I should have sent this a long time ago, but have been putting it off
>> in hopes that I would do more homework before sending this out. It
>> turns out that homework just never got done either :/. I just found
>> that kdepim master branch is depending on qtspeech so I thought I'd
>> send this out now and do my homework as I am able, possibly with some
>> answers on this thread to help me along.
>>
>> My main question is what is needed for qtspeech to get released?
>>
>> In looking at the code itself I see some commented out
>> structures/classes for the voice parameters. I guess for this to get
>> uncommented out a standard/common denominator between the 4 (or is it
>> 5 now) platforms that qtspeech will support needs to be found?
>
> Yes, language and voice settings are missing, that's the biggest issue.
>
>>
>> Is this the only thing holding qtspeech back from getting included in
>> an official Qt release? What else needs to be done for this to happen?
>
> I think the speech dispatcher code has problems, all other backends were
> written after and should be fine. The problem with spd is that the state
> (speaking etc) can get out of sync with what spd is actually doing and what
> qtspeech is reporting. This part should be re-done (possibly internally
> tracking a desired and real state).
>
> It may need some way to set the platform defaults (if it's to replace Jovie),
> though that can be added later.
>
> Finally it needs to be proposed for inclusion on the Qt 5 mailing list.
> Everything else I can take care of (including it in qt5.git as new module
> etc).
>
>>
>> I do realize that qtspeech wont write itself. I hereby commit myself
>> to help with at least the linux platform code. I don't have access to
>> a mac for development, so can't help there, but I can probably learn
>> to help with android and windows platforms if needed.
>
> If we nail down the API then implementing it is not so much work I imagine.
>
> Cheers,
> Frederik
>
>>
>> thanks,
>> Jeremy Whiting
>> _______________________________________________
>> Accessibility mailing list
>> Accessibility at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/accessibility
>
> _______________________________________________
> Accessibility mailing list
> Accessibility at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/accessibility