Scratch-vm: "Key pressed" block droppability behavior questions

[ericrosenbaum]

@kchadha and I noticed some questions that will come up again, once we re-implement the "key pressed" hat and boolean block with droppable inputs:

• How should we support key inputs that are not in the list, such as modifier keys, if at all? How would you enter them?
• What about non-english letters- should the key pressed block be able to detect those too if they get passed in?
• Currently you can pass in "left arrow" to detect the left arrow key. What if you're using scratch in another language- should this only use the english language string, or also match the localized one?
• What should it do if you pass in a longer string? Currently it matches the first character, so if you pass in "left arow" it matches the "l" key.

[thisandagain]

Strawcat Proposal:

• Do not support modifier keys (particularly as these may impact the use of screen readers / accessibility features)
• Support non-english unicode characters (e.g. "when [æ] key pressed", "key [ø] pressed?")
• Only support the "special" cases (such as the arrow keys) in english (as per the dropdown menu values). File a feature request issue to extend support on this to other languages (backlog).
• Only match the first character

[towerofnix]

What are opinions on detecting case-sensitive characters? For example, passing "key [a] pressed?" and "key [A] pressed?" would detect differently. I think this is okay since custom keyboard inputs are a pretty big possibility with this feature, but can't really be implemented as the "key pressed?" block is now, since we can't distinguish between upper- and lower-case keys being pressed.

I doubt this would have a negative effect on screen readers or similar tools, because I'm sure most would allow you to type capital letters, even if (they don't let let you specifically / it's difficult to) hold down shift.

This also falls in line a bit with @thisandagain's "support non-english unicode special characters" suggestion.

[thisandagain]

I think I'd rather detect both "a" and "A" as I'm worried about breaking compatibility / unexpected behavior when someone forgets they have the Caps Lock key enabled.