Skip to content
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

Allow braille display specific settings in the GUI #7452

Closed
leonardder opened this issue Jul 28, 2017 · 5 comments

Comments

@leonardder
Copy link
Collaborator

commented Jul 28, 2017

In NVDA's voice settings, a synthesizer can implement specific settings, such as inflection, etc. For this, the VoiceSettingsSlider class is available for use. I propose generalizing this custom settings system to allow custom settings for braille displays as well. Possibilities include:

  • Dot firmness
  • Enable/disable braille input. This is desirable for the handy tech driver, since one of the handy tech devices uses the space keys for either scrolling or braille input
  • Enable/disable active tactile control, also for Handy Tech devices

CC @bramd

@bramd

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2017

Looking at this code for speech synthesizers, I start to wonder if it would make sense to extend the SynthSettingsRing to a more generic quick settings ring and include some of the braille settings there as well. Any thoughts about this?

@bhavyashah

This comment has been minimized.

Copy link

commented Sep 16, 2017

@leonardder

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 29, 2017

@bhavyashah commented on 16 sep. 2017 15:30 CEST:

there is a rather small cross-section of NVDA users that use a
combination of speech and Braille full time.

Why do you think this is the case? From my experience as a trainer for visually impaired people, I can safely say this statement is, well, simply not true :)

Also note that the synth settings ring only shows its settings when there is an active synthesizer. The ring would also only show braille settings if the display supports them.

I think this must be delayed until #4877 is in core, that is, if we want to go for a generic approach for driver specific settings.

@leonardder

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 28, 2017

Making display specific settings available in the gui requires an initialized display to work with, which doesn't fit in the current UX. Therefore, it might be best to wait for #7302 to arrive.

leonardder added a commit to BabbageCom/nvda that referenced this issue Jan 3, 2018

leonardder added a commit to BabbageCom/nvda that referenced this issue Feb 15, 2018

michaelDCurran added a commit that referenced this issue Apr 20, 2018

Several improvements for the handy tech driver (#8016)
* Support time synchronization and fix reconnecting for bluetooth.

* Basic preparation for #7452

* Revert "Drop support for the Braillino for now"

This reverts commit fdd9c41.

* Basic support for old protocol

* More work on old protocol

* Support the old protocol

* cleanup

* Python3 compat

* Comments

* Use old protocol for easy braille

* Fixes

* Refactor onReceive

* Added support for Braillino and the old protocol

* Hopefully, some changes that ease python 3 porting in future

* Use old protocol for easy braille

* Last refactoring, including onReceive. Old protocol input is now dstable

* Remove the com server

* Review action

* Use Old Protocol for Braille Wave

* Catch ValueError for Handy Tech time sync datetime.datetime

@nvaccessAuto nvaccessAuto added this to the 2019.2 milestone May 16, 2019

feerrenrut added a commit that referenced this issue May 16, 2019

Allow setting braille display specific settings in the GUI (PR #8214)
Introduces an abstract driver class and allow the use of braille specific settings in the GUI

- Add HID input setting to ALVA and eurobraille drivers
- Add dot firmness setting to the handy tech driver
- Renamed availableInSynthSettingsRing to availableInSettingsRing. The old, deprecated classes from the synthDriverHandler still use availableInSynthSettingsRing for backwards compatibility

Closes #7452
@beqabeqa473

This comment has been minimized.

Copy link

commented May 18, 2019

hi.

found a regression.

when using synthiser which is using LanguageInfo class in synthDriver class an name error is thrown.

please fix this as soon as possible.

fix should be trivial, instead of ID write id in the following line.
super(LanguageInfo,self).init(ID, displayName)

should be

	super(LanguageInfo,self).__init__(id, displayName)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.