[Accessibility] qtspeech status

Wed Oct 22 11:10:35 CEST 2014

On Tuesday, October 21, 2014 08:14:12 AM Jeremy Whiting wrote:
> 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 ?
No, there isn't. So far I'm pretty much the only one who's been working on 
this library. If anyone is interested, here are all open changes to qtspeech 
(currently only Jeremy's):

https://codereview.qt-project.org/#/q/status:open+project:qt/qtspeech,n,z

Cheers,
Frederik

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