3 ms·

> Rather than have the app assume things about language, country defaults, and non-customization to try to select a hardcoded keymap this API just lets the app

> Rather than have the app assume things about language, country defaults, and non-customization to try to select a hardcoded keymap this API just lets the app reference the actual keymap directly without requiring the user to do anything. I think there's a really tangible difference between saying that AZERTY layouts prefer to use ZQSD for layout and saying that everyone is going to use the four keys on the left-hand side of the screen. It's sort of the same situation as controllers -- using physical maps to standardize controllers is just flat-out wrong, because different controllers have different conventions about what buttons in the same physical locations should commonly do. It's fine to say that there are common layouts that have defaults, but I think it's a much larger step to say that shortcuts/keybindings should be defined by physical location rather than convention. I don't completely see how that makes thing simpler for me as a developer (I don't want to intuit keyboard layouts by iterating over keys), and certainly I don't want it as a user. ---- > It's nice if this list can show the letter of the key, particularly once the user has left the config menu where you can reasonably show a full picture of the input device i.e. in use e.g. https://i.imgur.com/ZwVjubs.jpg https://i.imgur.com/ZwVjubs.jpg I have some other objections to your points below this (allowing applications to override user preferences is in fact a loss in user functionality, even if developers aren't forced to ignore those preferences), but I want to really focus in on this specific example, because you're not the first person I've seen bringing this up as a problem that needs to be fixed. And honestly, I really don't understand at all what people are talking about with this "fixing keymap messages" thing. I don't think I've ever had a problem with this[0]. Under the current scheme, before Chrome introduced this feature, it was impossible for a developer to mess this up. If you told the user to press "Z", and they pressed the key that they normally press to get "Z", no matter what their layout was or what their keyboard looked like your app would register a "Z" press. Whatever key you told them to press, if they pressed it you got that key. Perfect, impossible to break. But if you now are basing your prompts on a keymap that bypasses the user's keyboard layout and uses the physical position, and still labels those keys based on a QWERTY layout, then it is now possible to break the message and to tell the user to press the "Z" key, and then to have the "Z" key not work because what you're listening to is the physical location of the "Z" key on a QWERTY layout rather than the key that they use in their layout for typing a "Z". So I don't really understand what people are talking about with this objection; Chrome isn't fixing anything about user prompts because nothing needed to be fixed about matching user prompts to keybindings, it worked 100% of the time. The new feature actually breaks that and makes it possible to now implement user prompts that are inaccurate. I believe people who say they have struggled to implement this in the past, they wouldn't lie to me, but... for the life of me, I can't imagine how they're implementing keybindings then; I'm not sure what I could do architecturally to make inaccurate user prompts about keycodes into an issue for a webapp. ---- [0]: Okay, that's not quite true. I did have a problem with this once on a controller that mapped keys based on their physical location. The only time this has been a difficult problem for me to solve was when I was trying to figure out controller layouts and I realized that the letter painted on the controller button wouldn't consistently match up with the keycode across controllers.

zamadatix 5y ago
I think the first part largely comes down to an agreement of the second part so I'm going to skip to that for the moment, if it doesn't resolve with the second issue remind me and I'll come back to it. To the second part: say you have a positional input set in the game, e.g. "WASD" except which letters it actually is don't matter (because of either preference mapping or keyboard layout) just that they are positional inputs mapped to movement (up/left/down/right for your average WASD user), in such a case you also have positional support keys e.g. in an FPS commonly "action", "grenade", "strafe", "crouch", and so on. A sane default will usually have these all clustered together and laid out in a way the user can press common combinations easily (worth noting sane defaults aren't universal, what is good positioning for a particular binding in one game may be poor positioning in another that plays differently or has different mechanics) and a good game will allow these inputs to be remapped (be it for personal preference or accessibility). For the default mappings if you say "press F to pay respects" without an idea where "F" is because you don't have the keymap for the user either one of two things is going to happen when it's not the same as the developer's keymap: 1) You're using scancodes and the user actually needs to press "Q" or another random letter but you don't know how to tell them that because you don't have the keymap 2) You're using keycodes and the default mapping is completely garbage for the user. This will commonly lead to... 2a) The user goes to configure a custom positional mapping but because of 1) when they try to configure a custom mapping for the "Q" on their keyboard it shows "F" in the mapping (though works as expected) making custom mappings a PITA to configure. The way keycodes help the developer in these instances are: 1) You can display the actual letter for the default mappings, regardless if the user's keymap matches yours/your assumptions 2) You can display the actual letter for custom rebinds both in config and gameplay 3) If the user changes from DVORAK to QWERTY neither the developer or the user need to change anything for it to keep the positions/display the right letters . Now can this be misused to break things? Absolutely, a bad developer could misunderstand when to use keycodes vs when to use scancodes and in turn recreate a the problem class from 1). At the same time on native apps I can't say I've ever run into that vs the deluge of games and apps with positional bindings (typically content creation) that assume I'm QWERTY and look for the keycode. As for Office desktop as an example the character bindings still follow the character, e.g. I press ctrl+v to paste (which would be ctrl+o on a QWERTY layout) even though it has the ability to query the keymap for positional shortcuts.

zamadatix 5y ago

I think the first part largely comes down to an agreement of the second part so I'm going to skip to that for the moment, if it doesn't resolve with the second issue remind me and I'll come back to it. To the second part: say you have a positional input set in the game, e.g. "WASD" except which letters it actually is don't matter (because of either preference mapping or keyboard layout) just that they are positional inputs mapped to movement (up/left/down/right for your average WASD user), in such a case you also have positional support keys e.g. in an FPS commonly "action", "grenade", "strafe", "crouch", and so on. A sane default will usually have these all clustered together and laid out in a way the user can press common combinations easily (worth noting sane defaults aren't universal, what is good positioning for a particular binding in one game may be poor positioning in another that plays differently or has different mechanics) and a good game will allow these inputs to be remapped (be it for personal preference or accessibility). For the default mappings if you say "press F to pay respects" without an idea where "F" is because you don't have the keymap for the user either one of two things is going to happen when it's not the same as the developer's keymap: 1) You're using scancodes and the user actually needs to press "Q" or another random letter but you don't know how to tell them that because you don't have the keymap 2) You're using keycodes and the default mapping is completely garbage for the user. This will commonly lead to... 2a) The user goes to configure a custom positional mapping but because of 1) when they try to configure a custom mapping for the "Q" on their keyboard it shows "F" in the mapping (though works as expected) making custom mappings a PITA to configure. The way keycodes help the developer in these instances are: 1) You can display the actual letter for the default mappings, regardless if the user's keymap matches yours/your assumptions 2) You can display the actual letter for custom rebinds both in config and gameplay 3) If the user changes from DVORAK to QWERTY neither the developer or the user need to change anything for it to keep the positions/display the right letters . Now can this be misused to break things? Absolutely, a bad developer could misunderstand when to use keycodes vs when to use scancodes and in turn recreate a the problem class from 1). At the same time on native apps I can't say I've ever run into that vs the deluge of games and apps with positional bindings (typically content creation) that assume I'm QWERTY and look for the keycode. As for Office desktop as an example the character bindings still follow the character, e.g. I press ctrl+v to paste (which would be ctrl+o on a QWERTY layout) even though it has the ability to query the keymap for positional shortcuts.