[Accessibility] qtspeech status

Jeremy Whiting jpwhiting at kde.org
Tue Oct 21 02:42:54 CEST 2014


Apparently I'm too dumb to use gerrit. My git clone is from
and has a dev branch, but if I try to push it says I don't have
permissions. Maybe I just can't remember how I pushed my previous
change for review.
http://qt-project.org/wiki/Qt-Contribution-Guidelines suggests I add
some --codereview-user when I run init-repository, but I didn't ever
run that, so can't add that argument to set up a gerrit remote for
qtspeech. What's the "right way" to contribute to a qt module that's
not part of qt itself yet?

At any rate here's my first patch. It's a bit rough but it works for
speech-dispatcher backend here. I'll add empty/unimplemented methods
to the other backends if this looks ok to you and remove the commented
out stuff that this replaces also.


On Mon, Oct 20, 2014 at 11:13 AM, Jeremy Whiting <jpwhiting at kde.org> wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-locale-setting-and-available-locale-getting-meth.patch
Type: text/x-patch
Size: 9708 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/accessibility/attachments/20141020/39abbf88/attachment.bin>

More information about the Accessibility mailing list