Fix bug: menu items with variable titles and values failed to reset to their defaults after their key bindings were removed #4222
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.
Description:
If technical debt could be measured,
MenuController
should be declaring bankruptcy. Had to fight my natural tendency to try to go beyond and try to refactor it. But I think I found a solution which works fairly well, even though it's also kind of ugly.There are 16 menu items (which I found at least) in which
MenuController
will change the their title and associated data based on their value parameter. IINA has been deriving these based on their defaults inbindMenuItems()
at program start. It has also been deriving these from the user's active key bindings inupdateKeyEquivalentsFrom()
- but only if they matched one of the user's bindings.Unfortunately,
bindMenuItems()
doesn't cache the default values it generates, and there's no easy way to modify that method without it being a lot of work. However, thesettings
array inside theupdateKeyEquivalentsFrom()
method contains all the information needed in order to re-derive those default values. It's just necessary to supply the default values twice in order to be able to derive it via the existing code:Finally, this PR removes some code in
bindMenuItems()
which sets therepresentedObject
for those 16 fields at program load. They are completely unnecessary, because the updated code will get the same result when it callsupdateKeyEquivalentsFrom()
at program start. Following the DRY principle, it's important to remove them as a potential source of error, in case their values ever needed to be changed in the future.