[Accessibility] Accessibility Digest, Vol 5, Issue 1

Tue Oct 14 15:46:06 CEST 2014

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 <gladhorn at kde.org>
> 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 <jpwhiting at kde.org>
> Subject: Re: [Accessibility] qtspeech status
> To: Frederik Gladhorn <gladhorn at kde.org>
> Cc: accessibility at qt-project.org
> Message-ID:
> 	<CADWV2K4B13enug_vcK9BzLK48rUCRp6ez3ifyjMcUbUc3J9H1A at mail.gmail.com>
> 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 <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
>
> ------------------------------
>
> Message: 3
> Date: Mon, 13 Oct 2014 18:15:03 -0600
> From: Jeremy Whiting <jpwhiting at kde.org>
> Subject: Re: [Accessibility] qtspeech status
> To: Frederik Gladhorn <gladhorn at kde.org>
> Cc: accessibility at qt-project.org
> Message-ID:
> 	<CADWV2K6y8x-JEBWLHbBSZthe0h_Kx_o368ziu+houjTMO+5qHg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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
>
> ------------------------------
>
> Message: 4
> Date: Tue, 14 Oct 2014 13:21:58 +1100
> From: Luke Yelavich <luke.yelavich at canonical.com>
> 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
> *******************************************