From gladhorn at kde.org Mon Oct 13 10:41:35 2014 From: gladhorn at kde.org (Frederik Gladhorn) Date: Mon, 13 Oct 2014 10:41:35 +0200 Subject: [Accessibility] qtspeech status In-Reply-To: References: Message-ID: <4040037.7DttcpfO8Y@frederik-thinkcentre-m93p> 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 From jpwhiting at kde.org Mon Oct 13 21:56:46 2014 From: jpwhiting at kde.org (Jeremy Whiting) Date: Mon, 13 Oct 2014 13:56:46 -0600 Subject: [Accessibility] qtspeech status In-Reply-To: <4040037.7DttcpfO8Y@frederik-thinkcentre-m93p> References: <4040037.7DttcpfO8Y@frederik-thinkcentre-m93p> Message-ID: 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 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 From jpwhiting at kde.org Tue Oct 14 02:15:03 2014 From: jpwhiting at kde.org (Jeremy Whiting) Date: Mon, 13 Oct 2014 18:15:03 -0600 Subject: [Accessibility] qtspeech status In-Reply-To: References: <4040037.7DttcpfO8Y@frederik-thinkcentre-m93p> Message-ID: Frederik, On Mon, Oct 13, 2014 at 1:56 PM, Jeremy Whiting 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 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 From luke.yelavich at canonical.com Tue Oct 14 04:21:58 2014 From: luke.yelavich at canonical.com (Luke Yelavich) Date: Tue, 14 Oct 2014 13:21:58 +1100 Subject: [Accessibility] qtspeech status In-Reply-To: References: <4040037.7DttcpfO8Y@frederik-thinkcentre-m93p> Message-ID: <20141014022158.GA5483@acapella> On Tue, Oct 14, 2014 at 06:56:46AM AEDT, Jeremy Whiting wrote: > 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. At the moment a roadmap of future Speech Dispatcher development discussion is happening on the Speech Dispatcher list. One thing that Brailcom initially proposed, and I support, is moving Speech Dispatcher's configuration to gsettings. I would like to take this further, and allow clients to be able to configure settings themselves on a client basis, and it would be implemented such that the client would not know how the settings were being handled. So given this is implemented, I woudl see no reason for any of your code to wrap spd-conf, since spd-conf would likely be refactored to allw the user to configure Speech Dispatcher settings. Luke From fabrice.luneau76 at gmail.com Tue Oct 14 15:46:06 2014 From: fabrice.luneau76 at gmail.com (LUNEAU Fabrice) Date: Tue, 14 Oct 2014 15:46:06 +0200 Subject: [Accessibility] Accessibility Digest, Vol 5, Issue 1 In-Reply-To: References: Message-ID: <543D291E.6010509@gmail.com> Merci Donc je ne postule pas Je veux demander des renseignements à Atos sur cette formation http://www.cesi-entreprises.fr/actualites-formation-en-responsable-en-ingenierie-des-logiciels-en-partenariat-avec-atos-mission-emploi-handicap-bac4-en-alternance-mai-2014-orleans.asp En autre S'il y a des équivalences. Mais l'intitulé ne me parle pas. Pouvez -vous me donner votre avis. C'est à Orléans. Je veux bien aller en province, si c’est accessible. Il y a aussi des offres à Lille et Nantes. C'est mon nouvel axe de recherches. Le 14/10/2014 12:00, accessibility-request at qt-project.org a écrit : > Send Accessibility mailing list submissions to > accessibility at qt-project.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.qt-project.org/mailman/listinfo/accessibility > or, via email, send a message with subject or body 'help' to > accessibility-request at qt-project.org > > You can reach the person managing the list at > accessibility-owner at qt-project.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Accessibility digest..." > > > Today's Topics: > > 1. Re: qtspeech status (Frederik Gladhorn) > 2. Re: qtspeech status (Jeremy Whiting) > 3. Re: qtspeech status (Jeremy Whiting) > 4. Re: qtspeech status (Luke Yelavich) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 13 Oct 2014 10:41:35 +0200 > From: Frederik Gladhorn > Subject: Re: [Accessibility] qtspeech status > To: accessibility at qt-project.org > Message-ID: <4040037.7DttcpfO8Y at frederik-thinkcentre-m93p> > Content-Type: text/plain; charset="us-ascii" > > 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 > > > ------------------------------ > > Message: 2 > Date: Mon, 13 Oct 2014 13:56:46 -0600 > From: Jeremy Whiting > Subject: Re: [Accessibility] qtspeech status > To: Frederik Gladhorn > Cc: accessibility at qt-project.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > 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 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 > > ------------------------------ > > Message: 3 > Date: Mon, 13 Oct 2014 18:15:03 -0600 > From: Jeremy Whiting > Subject: Re: [Accessibility] qtspeech status > To: Frederik Gladhorn > Cc: accessibility at qt-project.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > Frederik, > > On Mon, Oct 13, 2014 at 1:56 PM, Jeremy Whiting 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 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 > > ------------------------------ > > Message: 4 > Date: Tue, 14 Oct 2014 13:21:58 +1100 > From: Luke Yelavich > Subject: Re: [Accessibility] qtspeech status > To: accessibility at qt-project.org > Message-ID: <20141014022158.GA5483 at acapella> > Content-Type: text/plain; charset=us-ascii > > On Tue, Oct 14, 2014 at 06:56:46AM AEDT, Jeremy Whiting wrote: >> 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. > At the moment a roadmap of future Speech Dispatcher development discussion is happening on the Speech Dispatcher list. One thing that Brailcom initially proposed, and I support, is moving Speech Dispatcher's configuration to gsettings. I would like to take this further, and allow clients to be able to configure settings themselves on a client basis, and it would be implemented such that the client would not know how the settings were being handled. So given this is implemented, I woudl see no reason for any of your code to wrap spd-conf, since spd-conf would likely be refactored to allw the user to configure Speech Dispatcher settings. > > Luke > > > ------------------------------ > > _______________________________________________ > Accessibility mailing list > Accessibility at qt-project.org > http://lists.qt-project.org/mailman/listinfo/accessibility > > > End of Accessibility Digest, Vol 5, Issue 1 > ******************************************* From jpwhiting at kde.org Tue Oct 14 20:23:55 2014 From: jpwhiting at kde.org (Jeremy Whiting) Date: Tue, 14 Oct 2014 12:23:55 -0600 Subject: [Accessibility] qtspeech status In-Reply-To: <20141014022158.GA5483@acapella> References: <4040037.7DttcpfO8Y@frederik-thinkcentre-m93p> <20141014022158.GA5483@acapella> Message-ID: Luke, Yeah, that's fine to remove spd-conf completely and use gsettings for settings, np. I was thinking the kcm would write to the .ini files themselves, but once speech-dispatcher is using gsettings I guess the kcm would need to link to glib and use the GSettings api to read/write configuration changes. I don't think that will be a problem though. And for power users they can use spd-conf itself currently, or use gsettings command-line arguments to change settings as needed (or if gnome comes up with a ui to tweak the gsettings, that works too I guess, maybe inside orca or whatnot, dunno). BR, Jeremy On Mon, Oct 13, 2014 at 8:21 PM, Luke Yelavich wrote: > On Tue, Oct 14, 2014 at 06:56:46AM AEDT, Jeremy Whiting wrote: >> 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. > > At the moment a roadmap of future Speech Dispatcher development discussion is happening on the Speech Dispatcher list. One thing that Brailcom initially proposed, and I support, is moving Speech Dispatcher's configuration to gsettings. I would like to take this further, and allow clients to be able to configure settings themselves on a client basis, and it would be implemented such that the client would not know how the settings were being handled. So given this is implemented, I woudl see no reason for any of your code to wrap spd-conf, since spd-conf would likely be refactored to allw the user to configure Speech Dispatcher settings. > > Luke > _______________________________________________ > Accessibility mailing list > Accessibility at qt-project.org > http://lists.qt-project.org/mailman/listinfo/accessibility From luke.yelavich at canonical.com Tue Oct 14 23:04:57 2014 From: luke.yelavich at canonical.com (Luke Yelavich) Date: Wed, 15 Oct 2014 08:04:57 +1100 Subject: [Accessibility] qtspeech status In-Reply-To: References: <4040037.7DttcpfO8Y@frederik-thinkcentre-m93p> <20141014022158.GA5483@acapella> Message-ID: <20141014210457.GA4996@acapella> On Wed, Oct 15, 2014 at 05:23:55AM AEDT, Jeremy Whiting wrote: > Luke, > > Yeah, that's fine to remove spd-conf completely and use gsettings for > settings, np. I was thinking the kcm would write to the .ini files > themselves, but once speech-dispatcher is using gsettings I guess the > kcm would need to link to glib and use the GSettings api to read/write > configuration changes. My thought is that you shouldn't have to worry about how Speech DIspatcher stores config changes, the API will likely be extended such that you can change the settings you want for the currently running client, and Speech Dispatcher takes care of storing them for you, no linking against glib explicitly. Luke From jpwhiting at kde.org Tue Oct 14 23:07:51 2014 From: jpwhiting at kde.org (Jeremy Whiting) Date: Tue, 14 Oct 2014 15:07:51 -0600 Subject: [Accessibility] qtspeech status In-Reply-To: <20141014210457.GA4996@acapella> References: <4040037.7DttcpfO8Y@frederik-thinkcentre-m93p> <20141014022158.GA5483@acapella> <20141014210457.GA4996@acapella> Message-ID: Ah through libspeechd itself? That would be awesome indeed. thanks, Jeremy On Tue, Oct 14, 2014 at 3:04 PM, Luke Yelavich wrote: > On Wed, Oct 15, 2014 at 05:23:55AM AEDT, Jeremy Whiting wrote: >> Luke, >> >> Yeah, that's fine to remove spd-conf completely and use gsettings for >> settings, np. I was thinking the kcm would write to the .ini files >> themselves, but once speech-dispatcher is using gsettings I guess the >> kcm would need to link to glib and use the GSettings api to read/write >> configuration changes. > > My thought is that you shouldn't have to worry about how Speech DIspatcher stores config changes, the API will likely be extended such that you can change the settings you want for the currently running client, and Speech Dispatcher takes care of storing them for you, no linking against glib explicitly. > > Luke From jpwhiting at kde.org Mon Oct 20 19:13:17 2014 From: jpwhiting at kde.org (Jeremy Whiting) Date: Mon, 20 Oct 2014 11:13:17 -0600 Subject: [Accessibility] qtspeech status In-Reply-To: References: <4040037.7DttcpfO8Y@frederik-thinkcentre-m93p> Message-ID: 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 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 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 From jpwhiting at kde.org Tue Oct 21 02:42:54 2014 From: jpwhiting at kde.org (Jeremy Whiting) Date: Mon, 20 Oct 2014 18:42:54 -0600 Subject: [Accessibility] qtspeech status In-Reply-To: References: <4040037.7DttcpfO8Y@frederik-thinkcentre-m93p> Message-ID: Frederik, Apparently I'm too dumb to use gerrit. My git clone is from git+ssh://jpwhiting at 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? 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 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 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 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: From frederik.gladhorn at theqtcompany.com Tue Oct 21 13:55:53 2014 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Tue, 21 Oct 2014 13:55:53 +0200 Subject: [Accessibility] qtspeech status In-Reply-To: References: Message-ID: <5803846.isoHQDXct0@frederik-thinkcentre-m93p> 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 at 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 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 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 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 From jpwhiting at kde.org Tue Oct 21 16:14:12 2014 From: jpwhiting at kde.org (Jeremy Whiting) Date: Tue, 21 Oct 2014 08:14:12 -0600 Subject: [Accessibility] qtspeech status In-Reply-To: <5803846.isoHQDXct0@frederik-thinkcentre-m93p> References: <5803846.isoHQDXct0@frederik-thinkcentre-m93p> Message-ID: 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 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 at 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 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 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 > 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 > From frederik.gladhorn at theqtcompany.com Wed Oct 22 11:10:35 2014 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Wed, 22 Oct 2014 11:10:35 +0200 Subject: [Accessibility] qtspeech status In-Reply-To: References: <5803846.isoHQDXct0@frederik-thinkcentre-m93p> Message-ID: <8740247.Yln59fbssp@frederik-thinkcentre-m93p> 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 > > 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 at 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 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 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 > > > > 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