Make keyboard layouts in charge of modifier keys and formatting of keys #257
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts commit 57a6ee7. It was not clear in issue jupyterlab#151 calling for a change in formatting of arrows that arrows should not be treated as modifier keys.
This puts the formatting of human-readable strings closer to where the keys are actually defined, and allows new keyboard layouts to extend this formatting for other keys the keyboard may have. This is exploratory work. It seems that the formatting of specific keys is not standardized across applications, operating systems, or keyboards, so I’m not sure if this will make anyone happier. It does seem like the keyboard layout is the right place for this formatting logic to happen for individual keys in the layout. I did verify that VoiceOver reads each of the macOS shortcuts correctly in menus (e.g., the curvy right arrow is read as “return” in a menu, etc.)
…g them. This adds a modifierKeys attribute to the keyboard layout so we can iterate over the modifier keys. Since we often want to our modifier keys displayed in a specific order, we need the modifier keys to be an ordered set, but Object.keys ordering is not guaranteed until ES2020, I believe. Therefore I converted the modifier keys to a Set, which does iterate in insertion order for sure. Finally, we make a kind of awkward special case for Command/Meta treatment on macos so that things are backwards-compatible with the current behavior. There are some blockers to further progress using getModifierState to determine modifier keys: 1. It does not appear that we can easily clone a KeyboardEvent and clone the getModifierState function, at least not as easily as we did for the standardized ctrl, shift, alt, etc. A way forward is that we could keep a reference to the original event and proxy getModifierState calls to the original event. 2. The current keyboard layout specifies the control key as “Ctrl”, not the standardized “Control” used in getModifierState. This is so that users can specify their keyboard shortcuts using “Ctrl” instead of “Control”. To make more progress here, we could use “Control” in the keyboard layout, and carefully trace where “Ctrl” was used and convert it to “Control” at the appropriate places.
We still keep the user-facing label as Ctrl for now for compatibility. This may be considered a breaking change in the keyboard package, since the layout has been changed to reference ‘Control’.
…to Control." This reverts commit bfdf926.
This preserves backwards compatibility for the keyboard layout, while still switching to getModifierState for checking the modifier state.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Currently, the commands package is in charge of formatting a keyboard shortcut for display and hard-coding the modifiers for a keyboard shortcut. However, this means that the modifiers and how keyboard keys are displayed are both hard-coded in the command package rather than being specified in the keyboard layout, which is closer to the keyboard capabilities.
I think ideally, the keyboard layout should be responsible for encoding the capabilities of the keyboard, including what the modifier keys are and how keys are displayed. This PR explores how this might work.
A couple of notes and unfinished business:
It may be that when we are ready to support keyboard layouts with other modifiers, it is appropriate to switch from using
.keyCodeto.key, which may make this PR obsolete.