Add "Only in edit controls" mode for typing echo#17505
Conversation
|
Great work on this, thank you. |
|
I think this needs a changelog entry as well. |
See test results for failed build of commit 8a5bed9868 |
See test results for failed build of commit 259e6d5452 |
|
Very nice addition @cary-rowen! Thanks. I have some questions:
|
nvdaes
left a comment
There was a problem hiding this comment.
@cary-rowen , thanks for this.
I think that you may add a helper function in globalCommands, similar to the toggleBooleanValue function, for config flags, and use it for toggling typed characters and words.
For reference, see toggleBooleanValue in globalCommands.py, introduced in PR #16994
…olean to integer conversion.
|
Hi @CyrilleB79
Could you please confirm if these behaviors are what you're asking about, and what the expected behavior should be in these cases? Many thanks |
|
Regarding default settings, I'd also love to hear suggestions from NV Access, I'd personally like to see new options provided as defaults for the same reasons as @CyrilleB79. @nvdaes |
|
@cary-rowen IMO, the expected behaviour with the new option in ssh password case and in read-only edit fields such as synthesizer is that NVDA should not speak anything since nothing is actually visible on the screen. |
|
thaaaaanks! should I really beleave that from now on we can get rid of the t. This pc 10 of 18, or space. playback stopped, and space. Playback resumed, with out needing to install the best ever addon made by @cary-rowen that addon was the best, because I alwayes liked and needed to keep typed characters and words, but I hated how they are announced everywhere, I was thinking, how stupid, the option it self is called speeck ('"typed"') characters and words, but why whe were hearing it everywhere? whe are not typing anything! whe are using our keyboard to use and explor our computer! but from now on, at least we don't have to use an addon to solv this really annoying this. And, really thank you @cary-rowen for resolving such problem for us until now. befor your addon releace on the stor, I was using an old and less buggy vertion of an unknown addon called typing settings to solv this for my self. greate feature! |
|
@cary-rowen speaking typed characters outside of edit fields does not make sense anyway, because they are not typed, but only pressed. For that we have the input help feature already if people need to learn the keyboard layout outside of edit fields. |
|
@Adriani90 hi. No, I also don't agree for removal of that in my opinion because, input help is a thing, but this is stil needed for some people where they need to press some keys and need to be announced for them what they've preased and what came up, or what happened as a result, while some newbie people need to turn on input help, press a fue keys that they need, and turn of input help, and make sure they've pressed or pressing the correct key. Also, for a groupe of users with old habit, better to not remove it but rename it instead for example, from on, to everywhere. so the options are as folows. off, in edit boxes only, everywhare. |
|
@CyrilleB79
I agree that there shouldn't be any feedback in the read-only edit box after enabling the new options introduced by this PR. This is currently as expected. cc @seanbudd |
|
I agree with @amirmahdifard I am totally not in favor of removing the original mode. |
e18a216 to
7c25e4c
Compare
nvdaes
left a comment
There was a problem hiding this comment.
@cary-rowen I've reviewed changes in globalCommands.py.
Looks good to me, except for minor inconsistencies in comments for translators.
SaschaCowley
left a comment
There was a problem hiding this comment.
Thanks @cary-rowen , looks good!
|
I've updated the original description with the latest changes. If there is anything else I need to do before merging please let me know. |
|
Thanks @cary-rowen, we're just waiting on @Qchristensen to look over the documentation changes. |
|
@cary-rowen please resolve merge conflicts |
Fixes #17637 Follow-up to #17505 Summary of the issue: The config upgrade steps for moving from version 14 to 15 of the config schema may leave the user's config in an invalid state if either of `["keyboard"]["speakTypedCharacters"]` or `["keyboard"]["speakTypedWords"]` is not a boolean. This is because the upgrade steps, as implemented, take no action if those values are not bools. For most upgrade steps, this approach is perfectly valid. However, version 15 of the schema expects these values to be integers, so validation of the upgraded config will fail. Description of user facing changes The configuration upgrade should not corrupt the user's config. Description of development approach Instead of just `return`ing when we get a `ValueError` in `upgradeConfigFrom_14_to_15`, delete the offending config entry. Testing strategy: Tested by creating valid and invalid config strings, instantiating `ConfigObj`s with them, and feeding those to `upgradeConfigFrom_14_to_15`. Known issues with pull request: A user may lose their setting for "Speak typed characters" or "Speak typed words", if configobj doesn't recognise it as a boolean. Theoretically this shouldn't be possible, as the config wouldn't have validated under any of the prior schema versions. Nevertheless this seems to have happened, and it is better to lose (at most) 2 settings than all settings.
) Fixes nvaccess#17637 Follow-up to nvaccess#17505 Summary of the issue: The config upgrade steps for moving from version 14 to 15 of the config schema may leave the user's config in an invalid state if either of `["keyboard"]["speakTypedCharacters"]` or `["keyboard"]["speakTypedWords"]` is not a boolean. This is because the upgrade steps, as implemented, take no action if those values are not bools. For most upgrade steps, this approach is perfectly valid. However, version 15 of the schema expects these values to be integers, so validation of the upgraded config will fail. Description of user facing changes The configuration upgrade should not corrupt the user's config. Description of development approach Instead of just `return`ing when we get a `ValueError` in `upgradeConfigFrom_14_to_15`, delete the offending config entry. Testing strategy: Tested by creating valid and invalid config strings, instantiating `ConfigObj`s with them, and feeding those to `upgradeConfigFrom_14_to_15`. Known issues with pull request: A user may lose their setting for "Speak typed characters" or "Speak typed words", if configobj doesn't recognise it as a boolean. Theoretically this shouldn't be possible, as the config wouldn't have validated under any of the prior schema versions. Nevertheless this seems to have happened, and it is better to lose (at most) 2 settings than all settings.
…controls'. (#17905) Fixes #17670 Summary of the issue: #17505 introduced the functionality where typed characters are only spoken when typing within editable controls. However, the input area in the modern Windows Calculator is not a standard editable control. Furthermore, it appears that almost any focused element within the Calculator can capture user input as part of the mathematical expression. Description of user facing changes Users will now hear typed characters in the Calculator even when the "Speak typed characters" option is set to 'Only in edit controls'. Description of development approach I handled the event_typedCharacter event within the "calculator" app module by temporarily switching the speakTypedCharacters mode to ALWAYS when the original setting is EDIT_CONTROLS, thereby ensuring NVDA reports the typed character. As noted above, since it seems almost any focused element in the Calculator accepts user input for the expression, I did not restrict this handling to specific objects within the Calculator. While this successfully restores the previous behavior, I have some reservations about this approach: Within the Calculator, the 'Only in edit controls' setting now behaves identically to 'Always'. If a user prefers not to hear typed characters in the Calculator specifically, they would have to turn the global setting off entirely. In the Calculator's "Converter" modes (e.g., Currency Converter, Temperature Converter), NVDA already announces the updated result with each keypress. With this change, NVDA will announce the typed character and the result, leading to the character being effectively spoken twice in quick succession, which might be slightly verbose or annoying.
Link to issue number:
Fixes #16848, related #10331, #3027
Summary of the issue:
Currently NVDA can only toggle typing echo (characters and words) on or off globally. Users want more granular control to only have typing feedback in edit controls, while keeping it off in other contexts like listss or non-edit areas.
Description of user facing changes
Description of development approach
The implementation:
Testing strategy:
Tested the following scenarios:
Known issues with pull request:
None identified.
Code Review Checklist:
@coderabbitai summary