KeyCode vs Key

[gossi]

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: https://github.com/IcarusWorks/ember-key-manager/blob/dc0db287261c49ef09d6077200a5fe6d7d48da8d/addon/services/key-manager.js#L125

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]

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]

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.