-
-
Notifications
You must be signed in to change notification settings - Fork 626
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit cursor blink rate #6470
Comments
This is an easy fix, and it seems unlikely anyone would want to set their cursor blink rate below say 200 ms (5 times a second), therefore P2. When implementing
|
@feerrenrut note that 0 is used for don't blink the cursor |
Fix for #6470, limit the minimum blink rate to 200ms
@derekriemer Thanks for pointing that out. Looking at the code, there does not seem to be any explicit decision for this behaviour, I think it more likely that this is a "happy accident" and probably a quirk of calling When the value is set to zero, I assume the cursor is present (but not blinking)? As opposed to being disabled which could be achieved with the Is this a valuable feature? Considering this is undocumented behaviour, are people currently disabling the blink for the cursor by setting it to zero? |
I probably should have thought of this. :) Actually, it's not an accident. See around line 1517 of braille.py:
Note the
Correct.
I think some users will want it, but maybe @dkager could shed more light? |
It wouldn't be hard to add an explicit option for this, however given its undocumented we should consider whether we should do this. |
It's certainly true that it's not documented, but I definitely knew about
this (my negligence in not flagging it during review notwithstanding). So,
I'm pretty sure it was intentional and it was just never documented
properly.
I'd be interested to know what UI other screen reader use for this setting.
|
Ok i'll extend my PR to cover this. |
Off the top of my head, SuperNova has different cursor shapes and has a blinking and a non-blinking version of each. That seems to be a bit muddy, the shape and the blinking are two separate things. The "0 to disable" semantics make more sense. I agree 200 ms is a sane minimum. Would rate limiting braille in general make be useful? E.g. when rapidly scrolling through a menu the display goes nuts too. |
Rate limiting the output of braille generally might make sense, but I think that should be handled as a different issue. While it could potentially share / change the implementation of this issue, it raises other questions and there are more things to consider than with limiting the cursor blink rate. If you would prefer not to have a new check box as an explicit way to disable cursor blinking please comment on the pull request #6558. Or if you would like to try out this implementation to see if it works for you take a look at branch |
Yes, rate limiting in general is a separate issue. It was just a side thought here. |
Introduce a way to use the GUI to disable cursor blinking. Rely on config update step to fix min values The config schema updates should now fix values below the minimum. Use validation data from config for min / max values in spin controls
Re issue #6470 Merge remote-tracking branch 'origin/i6470-LimitCursorBlinkRate' into next Conflicts: source/config/__init__.py To resolve, a line added to the configSchema needed to be moved into the configSpec.py file. The line was: readNumbersAs = integer(default=0,min=0,max=3)
- The minimum braille cursor blink rate is now 200ms. Profiles or configurations with values below this will be increased to 200ms. (Issue #6470) - A check box has been added to the braille settings dialog to allow enabling/disabling braille cursor blinking. Previously a value of zero was used to achieve this. (Issue #6470) - Profiles and configuration files are now automatically upgraded to meet the requirements of schema modifications. If there is an error during upgrade, a notification is shown, the configuration is reset, and the old configuration file is available in the NVDA log at 'Info' level. (Issue #6470)
Warning: the following STR may harm your display, don't try it with anything under 30 ms or so.
Your display's cursor will go nuts. Can this be limited to something like 150 ms to prevent damage to the pins being forced up and down so rapidly? I haven't seen damage ever, but accidentally did this, and it didn't sound good for the display.
The text was updated successfully, but these errors were encountered: