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

KeyCode vs Key #46

Open
gossi opened this issue May 28, 2018 · 2 comments
Open

KeyCode vs Key #46

gossi opened this issue May 28, 2018 · 2 comments

Comments

@gossi
Copy link

gossi commented May 28, 2018

I just run into the issue, that I am about to register shift + alt + cmd + f as macro. When you press and hold the alt key on a mac, the keyboard layout turns into something different and let's you access symbols. E.g. alt + f = ƒ. In order to register the macro alt + f on a mac, you need to register alt + ƒ as macro. It is not the key which is F but the representation of what they key is, when all modifiers applied. I ended up with a case, where my final key with all modifieres was an empty string. Something which is not appliable as a macro. This line:

It should be event.code instead of event.key (this would also fix #25). Sticking with event.key is error prone.

An idea would be to map the executionKey to their equivalent keyCode.

I subclassed your service in my app (basically for a nicer API of myself). I will play around with this and report back.

@gossi
Copy link
Author

gossi commented May 28, 2018

it's tricky. Let me describe the situation I'm in and how to use your library here.

In my app, I'll let the user define shortcuts. There is an input, when clicked records the shortcut and saves it. Also the shortcut is displayed in the UI. At the moment uses event.key property and if it is a special key, I have a map with symbols to use to display those. The keyboard layout (hardware and software) is the tricky thing here. E.g. I'm using a german mac keyboard layout. Means, my key left to y (the lower left alphabetic char on a qwertz layout) is a < and the respective event.code is IntlBackslash since I assume on an english keyboard it is the / key. Now given the following two use cases for a user, that wants to register two keyboard shortcuts:

  1. alt + f
  2. shift+ '<'

With two solutions:

  1. Using event.key this would be: alt + ƒ and shift + <`.
  2. Using event.code this would be: alt+ KeyF and shift+ IntlBackslash

The problem is double when displaying of the shortcut. I have a map that can be used to display code2symbol. Second is, the event.key is either filled with printable chars anyway the code is used instead [1]. So displaying with event.key and event.code will end up with the following:

  1. Using event.key will display: alt+ ƒ and shift+ <
  2. Using event.code will display: alt+ F and shift + /

My summary for the moment:

  1. Using event.code is less error prone and more straight forward (no handling with different execution keys when a modifier is pressed) but hard to display those shortcuts.
  2. Using event.key is easier to record and has the chance to using shortcuts that aren't registerable (when alt + key has an empty string representation and all the other keys are modifiers as well) and also displaying is problematic.

Given these and the chance of never been able to register a certain shortuct (alghouth possible) is inacceptable. To manoveur out of this displaying dilemma, there might be the possible to treat alphanumeric characters in a special manner. They are registered with their respective event.code (which is also easy generate 0 => Digit0 or f => KeyF), while the others are registered with event.key - though it is chaotic and crazy as you would assume at this moment.

Would love to get some input from you guys.

[1] https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key

@joshkg
Copy link

joshkg commented Sep 13, 2018

Here's another related wrinkle - in IE11 the 'escape' key event is 'Esc' whereas in most modern browsers it is 'Escape'. So if you register an execution key of 'Escape' it fails in IE11. Using event.keyCode seems another possibility rather than event.key.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants