Align braille input fall-back table to the default configuration (#9863) #9864
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Rebased onto latest master |
7 tasks
michaelDCurran
approved these changes
Sep 9, 2019
14 tasks
seanbudd
pushed a commit
that referenced
this pull request
May 7, 2024
Fixes #3304. Fixes #9863. Supersedes PR #9864, #10172. Addresses #505 (comment) Summary of the issue: In NVDA, there is no easy and reliable way for an add-on to provide a new braille table. For an experienced users wishing to do so there are two options: Alter manually an existing table in louis/tables. The new table still has its original name in the settings GUI. This change is lost upon NVDA updates. Set the absolute path to the table file in the configuration in lieu of the usual file name. The settings GUI shows an empty entry for this one. Forces to manually alter nvda.ini. Forces to copy in the same directory the whole dependency chain of the new table plus braille-patterns.cti. This is because liblouis default table resolver only looks for tables in a single directory, See Make it easier for add-ons to supply custom braille tables #5489 (comment) Description of how this pull request fixes the issue: Add a new brailleTables optional directory in both the user scratchpad directory and the add-on directory structure. Support reading tables metadata from an optional brailleTables section of the add-on manifest or from a manifest.ini file with the same format found in the root of the scratchpad directory, allowing a user to provide a display name and set output/input/contracted capabilities with no code. Implement a custom liblouis table resolver that resolves tables based on what is registered in the brailleTables module: When liblouis calls the resolver without a base file specified, the table is looked up from the brailleTables module and either resolved from the add-ons brailleTables directory or the built-in tables directory When liblouis calls the resolver with a base file specified (e.g. when processing includes in tables), the table is looked up from the folder of the base table and/or the built-in tables directory Enforce the existing fallback mechanism to ensure there still is braille output if the configured table cannot be found e.g. because an add-on or the scratchpad directory was disabled. This now applies both to the main configuration and individual profiles and also covers braille input. Note that if an add-on author wants a table to be listed in the GUI, he/she should always define the table in the manifest. Contrary to earlier incarnations of this pr, replacing a table in an add-on (i.e. when it has the same filename as a built-in table) without defining it in the manifest is no longer possible. Therefore it is also not possible to replace unlisted tables that are included by listed tables. For example, if you want to replace spaces.uti as included in nl-comp8.utb, you weel need to both define and bundle a replacement of nl-comp8.utb and spaces.uti in your add-on.
XLTechie
pushed a commit
to XLTechie/xlnvda
that referenced
this pull request
May 10, 2024
Fixes nvaccess#3304. Fixes nvaccess#9863. Supersedes PR nvaccess#9864, nvaccess#10172. Addresses nvaccess#505 (comment) Summary of the issue: In NVDA, there is no easy and reliable way for an add-on to provide a new braille table. For an experienced users wishing to do so there are two options: Alter manually an existing table in louis/tables. The new table still has its original name in the settings GUI. This change is lost upon NVDA updates. Set the absolute path to the table file in the configuration in lieu of the usual file name. The settings GUI shows an empty entry for this one. Forces to manually alter nvda.ini. Forces to copy in the same directory the whole dependency chain of the new table plus braille-patterns.cti. This is because liblouis default table resolver only looks for tables in a single directory, See Make it easier for add-ons to supply custom braille tables nvaccess#5489 (comment) Description of how this pull request fixes the issue: Add a new brailleTables optional directory in both the user scratchpad directory and the add-on directory structure. Support reading tables metadata from an optional brailleTables section of the add-on manifest or from a manifest.ini file with the same format found in the root of the scratchpad directory, allowing a user to provide a display name and set output/input/contracted capabilities with no code. Implement a custom liblouis table resolver that resolves tables based on what is registered in the brailleTables module: When liblouis calls the resolver without a base file specified, the table is looked up from the brailleTables module and either resolved from the add-ons brailleTables directory or the built-in tables directory When liblouis calls the resolver with a base file specified (e.g. when processing includes in tables), the table is looked up from the folder of the base table and/or the built-in tables directory Enforce the existing fallback mechanism to ensure there still is braille output if the configured table cannot be found e.g. because an add-on or the scratchpad directory was disabled. This now applies both to the main configuration and individual profiles and also covers braille input. Note that if an add-on author wants a table to be listed in the GUI, he/she should always define the table in the manifest. Contrary to earlier incarnations of this pr, replacing a table in an add-on (i.e. when it has the same filename as a built-in table) without defining it in the manifest is no longer possible. Therefore it is also not possible to replace unlisted tables that are included by listed tables. For example, if you want to replace spaces.uti as included in nl-comp8.utb, you weel need to both define and bundle a replacement of nl-comp8.utb and spaces.uti in your add-on.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Link to issue number:
Fixes #9863
Summary of the issue:
brailleInput.FALLBACK_TABLEis set to "en-us-comp8.ctb" as of 1c0d490 (2017-07-07)In
configSpec,["braille"]["inputTable"]default has been updated to "en-ueb-g1.ctb" as of 7cec335 (2017-08-01)Description of how this pull request fixes the issue:
Align the braille input fall-back table to the factory default for new configurations
en-ueb-g1.ctbTesting performed:
Known issues with pull request:
Change log entry:
Probably not worth mentioning