Key bindings for IINA commands: clean up & remove redundant code #5012
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:
Now that the fix for #4567 has been merged, it's clear that a lot of code for handling key bindings for IINA commands is now redundant because most of them are now being mapped to hidden menu items. This became apparent while examining PR #5005, which is adding a new command.
To be specific, of all the commands enumerated in
IINACommand.swift
, I found that nearly all of them are already being mapped to menu items inMenuController.updateKeyEquivalentsFrom()
, so the checks for these can be simply deleted fromPlayerWindowController.handleIINACommand()
and its overrides; they will never be used. I handled the remaining 5 commands as follows:flip
,mirror
: I migrated handling for these toupdateKeyEquivalentsFrom
. It was easy because all the objects were already created and easily referenced there.openFile
andopenURL
: I tried migrating these toupdateKeyEquivalentsFrom
, but for some reason, theOption
key was being added to their equivalents. Did not dig into why this was happening; just decided to leave them inhandleIINACommand
instead.deleteCurrentFileHard
: this is a less-used command, and it didn't have anNSMenuItem
object inMenuController
, so it would have required more code to migrate. I did move it up fromMainWindowController
toPlayerWindowController
so that it can also be recognized in music mode. I'm assuming that was an oversight when that feature was created.Note that this should be considered lower-priority and not merged too close to a release.