-
-
Notifications
You must be signed in to change notification settings - Fork 651
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
Backwards compatible control types refactor #12510
Conversation
0841b1f
to
8f8ea70
Compare
This comment has been minimized.
This comment has been minimized.
This is an awesome change! Could you consider the following while at it?
|
8d54ca0
to
92e4503
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
92e4503
to
8c2fdc9
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
740dfb7
to
50f88e5
Compare
See test results for failed build of commit aad9fadbb0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now I'll assume your self review has ensured that the movement of code hasn't introduced changes. I'll first focus on the layout and introduced code.
As usual, with moved code, we'll merge rather than squash merge. Can you confirm that the commits are logical for that please. I can recommend using the the "autosquash" feature in git. It makes it easier to keep track of what while be the final commits while making updates to them, addressing review actions etc.
…12510) - update coding standards for enum usage
6ee01a5
to
02785b9
Compare
…12510) - maintain backwards compatibility with * imports
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good, it's really close to being ready.
I have confirm there are only minor differences since the old HEAD 6ee01a53e
I have confirmed that the moved code still matches the old code from master, except for now using Enums and other minor changes. The code seems logically equivalent
I haven't yet confirmed everything previously exposed from controlTypes.py is exposed from controlTypes package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have confirmed (by comparing the files with git difftool origin/master:source/controlTypes.py HEAD:source/controlTypes/__init__.py
) that what is exposed from control types hasn't changed.
Another way to verify this may be to load use the NVDA python console:
- Import control types
pprint(dir(controlTypes))
.- Save this output for both before and after this change and compare with a diff tool.
The file controlTypes.py is already very complex and long, and the code can easily be divided into 5 groups. With the desire to group constants into Enums and maintain backwards compatibility, which adds length and complexity, it is a canidate to be split into submodules. Actions: - move controlTypes role data and functions to role.py - move controlTypes state data and functions to state.py - move isCurrent class to isCurrent.py - move outputReason to outputReason.py - move processing states functions to processAndLabelStates.py
In order to improve the NVDA API and internal typing, Enums are created for ROLE_* and STATE_* constants. Changes: - retain backwards compatibility until 2022.1 in controlTypes - improve type information for controlTypes processing - create a clickableRoles set in role.py for processAndLabelStates - update docstrings to reflect new types - lint controlTypes due to the mass changes - deprecate helper functions for processAndLabelStates - standardise members of the State enum from 0X[0-9]+ to 0x[0-9]+ - implement a displayStringEnumMixin - deprecate roleLabels, stateLabels, negativeStateLabels - update coding standards for enum usage and deprecations Co-authored-by: Leonard de Ruijter <leonardder@users.noreply.github.com>
c1621b8
to
f29cab9
Compare
In order to improve the NVDA API and internal typing, Enums are created for ROLE_* and STATE_* constants. Changes: - retain backwards compatibility until 2022.1 in controlTypes - improve type information for controlTypes processing - create a clickableRoles set in role.py for processAndLabelStates - update docstrings to reflect new types - lint controlTypes due to the mass changes - deprecate helper functions for processAndLabelStates - standardise members of the State enum from 0X[0-9]+ to 0x[0-9]+ - implement a displayStringEnumMixin - deprecate roleLabels, stateLabels, negativeStateLabels - update coding standards for enum usage and deprecations Co-authored-by: Leonard de Ruijter <leonardder@users.noreply.github.com>
f29cab9
to
8353f5f
Compare
This comment has been minimized.
This comment has been minimized.
I've updated the deprecations.md file to reflect your verification step, and changes.t2t |
See test results for failed build of commit 721241b832 |
See nvaccess/nvda#12510, nvaccess/nvda#11856 and nvaccess/nvda#12636 According to the NVDA change log: > - `characterProcessing.SYMLVL_*` constants should be replaced using their equivalent `SymbolLevel.*` before 2022.1. > - controlTypes has been split up into various submodules, symbols marked for deprecation must be replaced before 2022.1.
Link to issue number:
Closes #10732
Summary of the issue:
controlTypes.py
is a large file with many constants. To maintain backwards compatibility, the file length would increase to 1000+ LOC. It would be an improvement to split this code up, and group the constants into enums. As 2021.2 is not a compatibility breaking release, all changes must be backwards compatible.Description of how this pull request fixes the issue:
This is a large refactor. The changes are split into individual commits for reviewers.
The first commit can be reviewed using the following tool
The second commit is generated using the following sed commands.
The mixin strategy follows what is outlined for python 3.7 here. Mixins with Enums are fragile, and this code will have to be changed when updating (or downgrading python) Python.
Testing strategy:
Manual testing.
There is unit testing for the controlTypes module which should help ensure that compatibility doesn't break.
This module is fairly widely utilised, so any breaking changes are likely to be picked up quickly.
Known issues with pull request:
Changes can't be tracked backwards using git blame to
controlTypes.py
due to how the files are split up. As such, I've linted these files.I haven't implemented the enums in the wider NVDA codebase. When we break the backwards compatibility, by updating to 2022.1, we will need to update the rest of the NVDA code beforehand (see #12549).
Change log entries:
For developers:
controlTypes
has been split up into various submodules.ROLE_*
andSTATE_*
constants should be replaced to their equivalentRole.*
andState.*
before 2022.1. (Backwards compatible control types refactor #12510)roleLabels
,stateLabels
andnegativeStateLabels
have been deprecated, usages such asroleLabels[ROLE_*]
should be replace to their equivalentRole.*.displayString
orState.*.negativeDisplayString
before 2022.1. (Backwards compatible control types refactor #12510)Code Review Checklist: