[Accessibility] qtspeech status

Jeremy Whiting jpwhiting at kde.org
Tue Oct 14 02:15:03 CEST 2014


Frederik,

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).

I just read through qttexttospeech_unix.cpp and I don't see where the
problem is. Every time we get any callback from libspeechd in
speech_finished_callback we are updating the internal state. Where do
you see this problem?

thanks,
Jeremy

>>
>> 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



More information about the Accessibility mailing list