Skip to content

Make list of speech modes in the NVDA+s cycling script configurable.#15873

Merged
seanbudd merged 16 commits into
nvaccess:masterfrom
lukaszgo1:i15806
Dec 8, 2023
Merged

Make list of speech modes in the NVDA+s cycling script configurable.#15873
seanbudd merged 16 commits into
nvaccess:masterfrom
lukaszgo1:i15806

Conversation

@lukaszgo1

@lukaszgo1 lukaszgo1 commented Dec 3, 2023

Copy link
Copy Markdown
Contributor

Link to issue number:

Closes #15806

Summary of the issue:

NVDA allows to change the currently used speech mode by pressing NVDA+s. By default this gesture cycles between 'talk', 'beeps', 'on-demand' and 'no speech'. For many users having ability to switch to beeps or on demand is unnecessary, and they have no need for modes different than speech and no speech. For other beeps mode is certainly useful, but it is much more important to be able to quickly switch between speech and no speech, so beeps mode just makes the goal slower to achieve. With the introduction of fourth speech mode in #15804 it has been decided that users should be given ability to disable speech modes they do not need to use.

Description of user facing changes

The new checkable list containing all speech modes (all are initially checked)has been added into the Speech settings panel. When switching between modes with NVDA+s only modes which are checked in the list are included. When applying settings selected modes are validated, to make sure at least two modes are checked. When the 'talk' mode is disabled user is warned that they may be left without any speech.

Description of development approach

Configuration spec has been expanded to store list of disabled modes - this ensures that if any new mode is added to NVDA it is enabled by default in the cycling script. Speech settings panel now contains a list of all the speech modes, only enabled one are checked. When introducing validation for the speech settings panel it has been discovered that code responsible for checking panel's validity displays a warning about it being invalid, prevents saving invalid config, yet after dismissing the warning settings dialog gets closed. Since this is not optimal validation for settings dialog has been modified, so that after warning is dismissed settings remain open, and the invalid control is focused. The cycling script has been modified to only cycle between enabled modes. Unit tests verifying its behavior, both when no modes are disabled (the default) and some are disabled, were added. To make them work it has been necessary to perform a small modification to the method which lists configuration profiles in the config module, it assumed that profiles directory always exists, which is not true in unit tests. Now when the directory is missing appropriate warning is logged, and empty list is returned. User guide has been expanded to describe newly added control.

Testing strategy:

  • Executed unit tests
  • Manually verified various combinations of enabled and disabled modes
  • Ensured that when only one mode is checked appropriate error message is shown
  • Ensured that when 'talk' is disabled user is warned, and can either continue saving settings, or return to the list of speech modes
  • Verified that changes to the user guide can be compiled

Known issues with pull request:

  • Warning about 'talk' being disabled may be not optimal for users - if there is a lot of complaints about it we can always revert this part
  • Since the default mode is 'talk', yet it can be disabled it there is an inconsistency about what is used when starting NVDA, and to what mode NVDA can be switched. It has been proposed to allow configuring in which speech mode NVDA should start, but this was determined to be out of scope of this work
  • Currently change log recommends users to uninstall the NoBeepsSpeechMode add-on, as it is redundant, and hides the new on-demand speech mode. It should be possible to ask user if it should be uninstalled automatically, but that was also determined to be out of scope

Code Review Checklist:

  • Documentation:
    • Change log entry
    • User Documentation
    • Developer / Technical Documentation
    • Context sensitive help for GUI changes
  • Testing:
    • Unit tests
    • System (end to end) tests
    • Manual testing
  • UX of all users considered:
    • Speech
    • Braille
    • Low Vision
    • Different web browsers
    • Localization in other languages / culture than English
  • API is compatible with existing add-ons.
  • Security precautions taken.

@lukaszgo1 lukaszgo1 requested review from a team as code owners December 3, 2023 21:40
@lukaszgo1

Copy link
Copy Markdown
Contributor Author

@XLTechie @CyrilleB79 @LeonarddeR Since you expressed interest in #15806 you may want to review this PR.
@ABuffEr I would be curious if what has been proposed here is fine for you, and will allow you to sunset your NoBeepsSpeechMode add-on, i.e. do not update it for the 2024.1 compatibility.

Comment thread source/config/__init__.py
@AppVeyorBot

Copy link
Copy Markdown
  • FAIL: Translation comments check. Translation comments missing or unexpectedly included. See build log for more information.
  • PASS: Unit tests.
  • PASS: Lint check.
  • FAIL: System tests (tags: installer NVDA). See test results for more information.
  • Build (for testing PR): https://ci.appveyor.com/api/buildjobs/tavqdfvtxs9apqsi/artifacts/output/nvda_snapshot_pr15873-30175,b7abfe1b.exe
  • CI timing (mins):
    INIT 0.0,
    INSTALL_START 0.9,
    INSTALL_END 1.0,
    BUILD_START 0.0,
    BUILD_END 24.9,
    TESTSETUP_START 0.0,
    TESTSETUP_END 0.3,
    TEST_START 0.0,
    TEST_END 16.2,
    FINISH_END 0.1

See test results for failed build of commit b7abfe1b7c

@ABuffEr

ABuffEr commented Dec 3, 2023

Copy link
Copy Markdown
Contributor

@ABuffEr I would be curious if what has been proposed here is fine for you, and will allow you to sunset your NoBeepsSpeechMode add-on, i.e. do not update it for the 2024.1 compatibility.

Oh yes, to all questions!
I just played with this PR for some minutes, and personally find the talk/on-demand combination very comfortable for me.
Small, great work.

@seanbudd seanbudd left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @lukaszgo1

Comment thread source/speech/speech.py
Comment thread source/globalCommands.py Outdated
Comment thread source/gui/settingsDialogs.py Outdated
Comment thread source/gui/settingsDialogs.py Outdated
Comment on lines +1696 to +1707
if not any(
self._allSpeechModes[i].producesSpeech for i in enabledSpeechModes
):
log.debugWarning("None of the speech modes producing speech are enabled. This configuration is invalid.")
gui.messageBox(
# translators: Message shown when none of required speech modes are enabled.
_("One of speech mode talk or on-demand has to be enabled."),
# Translators: The title of the message box
_("Error"),
wx.OK | wx.ICON_ERROR,
self
)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this necessary? wouldn't there be some utility in switching between beeps and off for some (partially sighted) users or for particular application configuration profiles?
I can't think of a use case, but I'm just concerned about artificially limiting configurability where there's no technical need to do so.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm actually looking at this from another view point. Note that the default speech mode is talk. If you add a possibility to disable the talk mode, there is a bit of an inconsistency of what's the cold start default and what's configurable. I'd personally limit the list to beeps and on demand and always show the off and talk modes.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been discussed at lengths in #15806, where the following conclusions were reached:

  • Some users do not need to have the 'off' mode enabled, since they either want full speech, or beeps, which are just an indication that something has happened. While @XLTechie explicitly requested an ability to disable the 'off' mode, I can also see some usefulness in this i.e. in a separate profile for terminals, where I'm either working with full speech, or just want to have an indication that something is happening, and 'beeps' mode is ideal for such things. In short it should be possible to disable the 'off' mode.
  • It is also very likely that for someone using primarily magnification the 'talk' mode is not necessary, and is as annoying when switching between modes as the 'on-demand' mode for people who have no use for it. That is why the 'talk' mode is on the list and can be unchecked.
  • The current validation has been implemented like this to make sure user is never in a situation in which they are left without any speech. Thinking about use cases for having only 'beeps' and 'off' modes enabled the only one I could came up with is a Braille only user who works without any speech most of the time, but uses 'beeps' mode similarly to what has been described above, i.e. as a quick indication that something has happened in the console when they're not looking at their Braille display. It seems there are two choices here:
    • We can start by not limiting the configurability i.e. allow to disable both 'talk' and 'on-demand' modes, and if there is a lot of complaints about this design implement something better according to user's feedback. or
    • Start with the current design, and if someone reports that it is too limiting for their clear defined use case make this more configurable later.

I personally prefer the first option, as it is much easier to react to user feedback and make something simpler, than start with a limited config which is not working for some.

  • The inconsistency argument is certainly valid. This can also be addressed in two ways:
    1. We can assume that configurations where 'talk' mode is disabled are pretty rare, done by mostly advanced users, and simply ignore the inconsistency
    2. We can do something similar to what has been implemented in JAWS, i.e. add additional control where it is possible to select in which speech mode NVDA should start. In that case I propose to modify the validation for the list of enabled speech modes, so that it it would be impossible to disable the speech mode defined as the one in which NVDA starts.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'd prefer the following based on your thoughts:

  1. Start with not limiting the configurability, though it makes sense to ensure that at least one option is enabled.
  2. Allow configuring the start mode

Comment thread tests/unit/test_globalCommands.py Outdated
Comment thread tests/unit/test_globalCommands.py Outdated
Comment thread user_docs/en/changes.t2t Outdated
Comment on lines +34 to +36
- it is now possible to exclude unwanted speech modes when cycling between them using ``NVDA+s`` from the Speech category in NVDA's settings. (#15806, @lukaszgo1)
- If you are currently using the NoBeepsSpeechMode add-on consider uninstalling it ,and disabling "beeps" and "on-demand" modes in the settings.
-

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think mentioning the add-on is relevant in the core change log. We haven't done this historically when other add-ons have been integrated (e.g. add-on store, OCR).
I've also move the sentence around to be clearer.

Suggested change
- it is now possible to exclude unwanted speech modes when cycling between them using ``NVDA+s`` from the Speech category in NVDA's settings. (#15806, @lukaszgo1)
- If you are currently using the NoBeepsSpeechMode add-on consider uninstalling it ,and disabling "beeps" and "on-demand" modes in the settings.
-
- In the NVDA's settings Speech category, it is now possible to exclude unwanted speech modes when cycling between them using ``NVDA+s``. (#15806, @lukaszgo1)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the add-on cause issues with this new feature? We did mention removing the add-on for highlighting but that's because they conflicted with each other.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I just tried, and it apparently gives no errors, but hides completely the new functionality and, moreover, the new on-demand speech mode.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for testing. That sounds like a bad conflict! We should definitely encourage uninstalling

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note that the add-on will be marked incompatible anyway, so I'm not sure whether it should be addressed. People should no longer update it.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mentioned add-on in the change log since:

  • it is pretty popular
  • it has even been mentioned in the NV Access training materials, and I'm not sure how easy is to update them (especially the audiobook and printed Braille copy), therefore mentioning that NoBeepsSpeechMode is unnecessary somewhere which is localized seemed a right thing to do
  • With the newly added ability to override compatibility for add-ons the fact that add-on is no longer compatible is much less important. Most users would override compatibility if no updated version is available, so mentioning in the change log that there is a core function which should be used instead is the least we can do to discourage forcefully enabling the add-on

Personally I think we may consider going even a step further i.e. detect NoBeepsSpeechMode in the core, if its enabled let user know that it is no longer needed, offer to configure NVDA in the same way it behaved with the add-on and uninstall it. While that would be a new paradigm in NVDA I'd say it is worth considering.

Comment thread user_docs/en/userGuide.t2t Outdated
Comment thread user_docs/en/userGuide.t2t Outdated
Comment thread user_docs/en/userGuide.t2t Outdated
@seanbudd seanbudd marked this pull request as draft December 4, 2023 01:56

@CyrilleB79 CyrilleB79 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Many thanks @lukaszgo1 for this work that was requested after my previous PR.

One thing that I have noted:
When NVDA starts or when the config is reset, speech mode turns back to Talk, no matter if Talk is in available in the cycle speech mode command; this was already the case in NVDA 2023.3. I think it's not a problem, and it can be a security so that a user does not end with NVDA starting only with mode off and beep available.
When switching profile however, the speech mode is not changed, what makes sense.

Comment thread source/config/configSpec.py
Comment thread source/globalCommands.py Outdated
description=_(
# Translators: Input help mode message for cycle speech mode command.
"Cycles between the speech modes of off, beep, talk and on-demand."
"Cycles between enabled speech modes."

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"enabled" may let one think that a speech mode is active.

Using "available" is less confusing IMO.

Suggested change
"Cycles between enabled speech modes."
"Cycles between available speech modes."

or just:

Suggested change
"Cycles between enabled speech modes."
"Cycles between speech modes."

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed in 927918c. I went wit your second suggestion, since it is much simpler. My original idea was to use 'available and 'enabled' in a similar sense they're used for add-ons i.e. each mode in NVDA is available, but only these which are configured are enabled.

Comment thread source/globalCommands.py
Comment thread source/gui/settingsDialogs.py
Comment thread source/gui/settingsDialogs.py Outdated
_("Error"),
wx.OK | wx.ICON_ERROR,
self
)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this part of code should go away, so that not to create an unneeded constraint.

Anyway, if it is chosen to keep it, a return statement is missing:

Suggested change
)
)
return False

Comment thread user_docs/en/userGuide.t2t Outdated
Comment thread user_docs/en/userGuide.t2t Outdated
Comment thread user_docs/en/userGuide.t2t Outdated
Comment thread source/gui/settingsDialogs.py Outdated
Comment thread user_docs/en/userGuide.t2t Outdated
@XLTechie

XLTechie commented Dec 4, 2023 via email

Copy link
Copy Markdown
Collaborator

@XLTechie

XLTechie commented Dec 4, 2023 via email

Copy link
Copy Markdown
Collaborator

Comment thread source/globalCommands.py
@lukaszgo1

Copy link
Copy Markdown
Contributor Author

I have updated the initial description of this PR. In short currently the only validations for the checked modes ensures that there are at least two checked.
There are two alternative, and not totally exclusive, proposals:

  1. Show a informational dialog, with yes and no, which warns user when they disabled both 'talk' and 'on-demand' modes
  2. Since it is currently possible to set NVDA so that it switches only between 'off' and 'beeps' yet the initial mode is 'talk' which is inconsistent, it has been proposed to allow setting in which speech mode NVDA initially starts.

It is also worth discussing if NVDA should not detect that users had NoBeepsSpeechMode installed, and propose to uninstall it, perhaps configuring NVDA to mimic the add-on's behavior.
I feel both of these require product decision from NV Access. @michaelDCurran @seanbudd Would you be able to share your opinion?

@seanbudd

seanbudd commented Dec 6, 2023

Copy link
Copy Markdown
Member

I think the lowest impact and simplest UX is the warning dialog - we can always change the UX further in the future,

@lukaszgo1

Copy link
Copy Markdown
Contributor Author

I have mentioned things which were proposed during review in the known issues of the initial comment, so that they're not lost. Otherwise this is ready to be reviewed.

@lukaszgo1 lukaszgo1 marked this pull request as ready for review December 7, 2023 12:31
Comment thread source/gui/settingsDialogs.py Outdated

@XLTechie XLTechie left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work @lukaszgo1! Some suggestions below, mainly on comments and docs.

Comment thread source/globalCommands.py Outdated
Comment thread source/globalCommands.py Outdated
Comment thread source/gui/settingsDialogs.py Outdated
Comment thread source/gui/settingsDialogs.py Outdated
Comment thread source/speech/speech.py Outdated
Comment thread source/speech/speech.py Outdated
Comment thread user_docs/en/changes.t2t Outdated
Comment thread user_docs/en/userGuide.t2t Outdated
Comment thread user_docs/en/userGuide.t2t
Comment thread user_docs/en/userGuide.t2t Outdated
lukaszgo1 and others added 2 commits December 7, 2023 18:04
Co-authored-by: Cyrille Bougot <cyrille.bougot2@laposte.net>
Co-authored-by: Luke Davis <8139760+XLTechie@users.noreply.github.com>
@lukaszgo1

Copy link
Copy Markdown
Contributor Author

@CyrilleB79 @XLTechie Many thanks for your review! I believe all your comments are now addressed.

@seanbudd seanbudd left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @lukaszgo1

Comment thread user_docs/en/changes.t2t Outdated
Comment thread user_docs/en/userGuide.t2t Outdated

@Qchristensen Qchristensen left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good and will be a welcome feature for users, great work everyone!

@seanbudd seanbudd merged commit fc3489a into nvaccess:master Dec 8, 2023
@nvaccessAuto nvaccessAuto added this to the 2024.1 milestone Dec 8, 2023
@XLTechie

XLTechie commented Dec 8, 2023

Copy link
Copy Markdown
Collaborator

@CyrilleB79 While this has been merged, I wanted to address your outstanding comment in response to me.

You disagreed with my suggestion to add the warning dialog note to the user guide.
My thinking was that users may be more inclined to experiment, if they know they will get a warning about doing something potentially dangerous, or that will cause them to lose speech.

There are a few other cases of warning dialogs being spoken of in the user guide, such as in relation to incompatible add-ons, and the screen curtain, though this is by no means consistent.

I do understand your point of view, and I have no strong opinion either way about whether to include the note about the warning. But I wished you to understand why I made the suggestion in the first place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

List of speech modes which can be switched to with NVDA+S should be made configurable

10 participants