Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Refactor/fix handling of special keys in integrations
Evaluating `globalKeyboardShortcut(_:)` revealed several issues with related to special keys: - Shortcuts using the `Key.space` would produce a `KeyEquivalent` that specified the "S" key. (cause: `first` being used on the `keyToCharacter()` return value, `"space"`) - Shortcuts using `Key.f*` would produce a `KeyEquivalent` that Specified the "F" key. (cause: same as above) - Shortcuts using `Key.keypad*` would produce a `KeyEquivalent` that was not limited to the number pad. (cause: neither SwiftUI nor AppKit make this distinction when producing menu items) Considering these issues, a reevaluation of special keys' handling is called for. Excepting the `Carbon` integration that drives the actual keyboard shortcuts, there are three distinct contexts where a `Shortcut` is used: - `Recoder`: where an `NSString` is produced to go into the `TextField` displaying the shortcut's current value - `NSMenuItem`: for specifying `keyEquivalent` and `keyEquivalentModifierMask` - `toSwiftUI`: for creating a `SwiftUI.KeyboardShortcut` Ideally, each of these three do their work in analogous ways. This branch accomplishes this with the following: - `SpecialKey` enumerates the cases that require extra attention. This is drawn directly from keys used in `keyToCharacterMapping` and used to ensure that each special case is handled. - Three mappings for `SpecialKey` are created for each of the three contexts where the handling is important: `presentableDescription`, `swiftUIKeyEquivalent`, and `appKitMenuItemKeyEquivalent`. - In these three contexts if there is a `SpecialKey`, the defined mapping is what rules. `keyToCharacter()` is used if and only if there is no `SpecialKey` available. An assertion to this effect is added. Fixes: #192
- Loading branch information