Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broaden the scope of the specification to support web IDEs #26

Open
spoenemann opened this issue Mar 15, 2019 · 0 comments

Comments

@spoenemann
Copy link

commented Mar 15, 2019

The current draft states the following non-goals:

  • Identifying a keyboard layout or locale
  • Being able to convert from a code value + modifiers into the key value that would be generated by the current locale and layout with those modifiers present.
  • Being able to convert from a key value into the set of code values required to generate that value, given the current locale and layout.

I understand that for the currently described user scenario, keypress instructions in games, this is acceptable. There is another scenario that is unsufficiently supported by web APIs: command keybindings in web IDEs. In this other scenario, the three stated non-goals are exactly the missing piece that would allow to handle keybindings for IDE commands properly. This can be explained best with an example.

Example

The Visual Studio Code keybinding for the command "Toggle Line Comment" is Ctrl+/ on Windows and Cmd+/ on Mac with US keyboard layout. On many other keyboard layouts, the / character does not have its own key, so the keybinding has to be changed to something else. For German keyboards, VS Code has solved it by using Ctrl+# on Windows and Cmd+Shift+7 on Mac (Shift+7 produces the character / on German keyboards).

VS Code is an Electron application and uses the native-keymap package to determine the keyboard layout (see microsoft/vscode#713). Since that is an OS-native library, it cannot be used in a web application.

Rationale

If we would have a web API that allows us

...to convert from a code value + modifiers into the key value that would be generated by the current locale and layout with those modifiers present,

a web IDE could identify the complete keyboard layout and thus adapt the configured keybindings to the user's keyboard. This is exactly the kind of information that is provided by the native-keymap package for VS Code.

The inverse mapping, that is the ability

...to convert from a key value into the set of code values required to generate that value, given the current locale and layout,

would be useful, too, in that context, though it could also be derived from the mapping above and thus does not add any new information.

In case a web IDE would like to display the detected keyboard layout to the user,

identifying a keyboard layout or locale

would be necessary.

In summary, web IDEs need some means to query the mappings from code values to key values for all combinations of the Shift and Alt modifiers. The other extensions can be useful, but can be regarded as optional.

Proposal

The current proposal of the Keyboard interface could be extended so the getLayoutMap() function takes an optional first argument with the structure { shiftKey: boolean, altKey: boolean }. If such an argument is given, it returns the KeyboardLayoutMap that considers those modifiers, otherwise it behaves as described in the current proposal.

Background Information

As a committer of Eclipse Theia, my main motivation is to improve support for international keyboard layouts in that web IDE. Theia is currently used in

Of course other web IDEs could also greatly benefit from better keyboard layout support in the web API, for example

Web IDEs are emerging very quickly, which shows that there is a high demand for them. However, the web APIs are not prepared for this kind of user scenario when it comes to keyboard events.

Privacy Considerations

The impact on users' privacy is basically the same as for the currently proposed API (see #8). Of course adding modifiers to the keyboard layout information increases the fingerprint in terms of the amount of data, but I assume it does not change much about the identifiability of a certain keyboard because most keyboards should be already fully identified by their character layout without modifiers. This assumption needs to be verified, though.

How to Proceed?

I am submitting this issue because the current keyboard-map proposal is already quite close to the needs of web IDEs. The missing piece are the modifier keys.

If you think what I describe would be better put into a separate draft, I'm fine with that. My intention is to start a discussion on this so eventually we can improve the user experience for web IDEs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.