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 |
feerrenrut
left a comment
There was a problem hiding this comment.
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.
34d3e8b to
46f51d8
Compare
- retain backwards compatibility until 2022.1 in controlTypes - move controlTypes role data and functions to rol.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
- improve type information for controlTypes processing - create clickableRoles set in role.py
- add displayStringEnumMixin - deprecate roleLabels, stateLabels, negativeStateLabels Co-authored-by: Leonard de Ruijter <leonardder@users.noreply.github.com>
46f51d8 to
54f930b
Compare
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
feerrenrut
left a comment
There was a problem hiding this comment.
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.
feerrenrut
left a comment
There was a problem hiding this comment.
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>
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 |
Link to issue number:
Closes #10732
Summary of the issue:
controlTypes.pyis 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.pydue 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:
controlTypeshas 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,stateLabelsandnegativeStateLabelshave been deprecated, usages such asroleLabels[ROLE_*]should be replace to their equivalentRole.*.displayStringorState.*.negativeDisplayStringbefore 2022.1. (Backwards compatible control types refactor #12510)Code Review Checklist: