braille: optionally speak line when moving from line to line

[burmancomp]

Is your feature request related to a problem? Please describe.

Likely many braille users in many cases use both braille and speech simultaneously. Thus it would be useful when nextLine and previousLine functions are executed that optionally also new line would be spoken.
Firstly I thought this would be useful when braille is tethered to focus but now I think it should be available when braille is tethered to review as well.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

[nvdaes]

I'm interested in this. I inform in case original reporters want to open a PR. I may do it since it doesn't exist.
If so, I think that a keystroke to enable and disable it may be useful, since this can be useful, for example, for certain lines, not always.

[nvdaes]

AlsAlso, I think that we can see if this can be done when using the scroll feature, not just when moving throught lines. Perhaps we can use an enum to expand info unit characters, unit lines, etc.

[burmancomp]

Feel free to open pr.

[nvdaes]

Thanks. At least for now, I'll focus my work on next and previous line functions, not on scroll forward and backward.
Also, I think that, if NVDA is configured to read by paragraphs, the whole paragraph can be read.
My approach would be to create a checkbox and a boolean.

[CyrilleB79]

Are you speaking of commands to move the review cursor to previous/next line? These commands are mapped to braille keys, e.g. left joystick up/down in my case with Esys.

I have the feeling that this new option could be commonalized with "Speak character when routing cursor in text" option in some way. What do you think?

[nvdaes]

Are you speaking of commands to move the review cursor to previous/next line? These commands are mapped to braille keys, e.g. left joystick up/down in my case with Esys.
I have the feeling that this new option could be commonalized with "Speak character when routing cursor in text" option in some way. What do you think?

I have thought this too, but after seeing the source code I think that this is not easy.
I think we should use the dest variable available in next and previous line functions, and this is not similar to the _speakOnrouting function.

[burmancomp]

I think we should use the dest variable available in next and previous line functions.

This sounds good. I somewhat think that as expanded dest should be suitable for speech (at least in quite many cases).

[burmancomp]

I somewhat think that as expanded dest should be suitable for speech (at least in quite many cases).

Hopefully it is suitable but I am not sure at all that it is.

[burmancomp]

@nvdaes sorry that although you are opening pr for this I however tell my test results.

I added following to the end of nextLine and previousLine functions, and ran that modified source:

speech.cancelSpeech() dest.expand(textInfos.UNIT_LINE) speech.speakTextInfo(dest, unit=textInfos.UNIT_LINE, reason=controlTypes.OutputReason.CARET)

Why cancelSpeech? If scroll forward and scroll back buttons do not interrupt speech, previous line may still be spoken when you move to next line.

Could you take this "cancel possible current speech when moving from line to line" into account in your implementation?

[nvdaes]

Could you take this "cancel possible current speech when moving from line to line" into account in your implementation?

Yes. My computer is broken now and I may not open PR until next week.
If you prefer to open it yourself, feel free to do it, or wait for me.

[burmancomp]

Could you take this "cancel possible current speech when moving from line to line" into account in your implementation?

Yes. My computer is broken now and I may not open PR until next week. If you prefer to open it yourself, feel free to do it, or wait for me.

Thank you, I wait for you. If it is ok I can tell if I find something I think could be useful.

[nvdaes]

Hello. Seems that cancelSpeech is not needed. I've created a function to speak next and previous lines and paragraphs, deppending on the selected reading unit for braille.
I'll open a PR.
Note that in consoles this may not work well, i.e., since a caret is not available, lines aren't spoken.
This ma require to change the next and previous line navigation functions in braille.py.