[Accessibility] qtspeech status

[Jeremy Whiting]

Frederik,

No thoughts so I'll continue as outlined below. I think option 2 makes
the most sense since we already have api to set pitch/rate/volume, so
I'll add setting the language, name/id, gender and add the new api to
the backends or add methods that have qWarning() this isn't
implemented on this platform" and send to gerrit for review. I'll
remove the commented out Voice class which just held a name and
locale, and all properties of speech will be separate. I guess if
setting one property like language changes other properties like name
or whatnot we can/should emit signals that the other property changed
as well. Does that sound ok?

thanks,
Jeremy

On Mon, Oct 13, 2014 at 1:56 PM, Jeremy Whiting <jpwhiting at kde.org> wrote:
> 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