[Accessibility] qtspeech status

Tue Oct 21 16:14:12 CEST 2014

Nope, I missed that in the guide somehow. Did that now and added
Frederik as reviewer. Is there a way to add the whole accessibility
list as reviewer so comments will go to the list ?

On Tue, Oct 21, 2014 at 5:55 AM, Frederik Gladhorn
<frederik.gladhorn at theqtcompany.com> wrote:
> On Monday, October 20, 2014 06:42:54 PM Jeremy Whiting wrote:
>> Frederik,
>>
>> Apparently I'm too dumb to use gerrit. My git clone is from
>> git+ssh://jpwhiting@codereview.qt-project.org:29418/qt/qtspeech.git
>> 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?
>
> Did you push to HEAD:refs/for/dev ?
> Cheers,
> Frederik
>
>>
>> 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.
>>
>> thanks,
>> Jeremy
>>
>> 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
>