Suggestion: Menu items for control, shift, delete, backspace, and enter

[AmazingMech2418]

Expected Behavior

If the suggestion was followed, there would be more keys added for the key pressed boolean

Actual Behavior

There aren't menu items for the keys mentioned in the title of this issue.

Steps to Reproduce

It always happens and this is just a suggestion.

Operating System and Browser

It doesn't really matter. This is a suggestion.

[AmazingMech2418]

I already have it ready for backspace, delete, and enter...

[towerofnix]

Some example uses would be helpful. So here's a few:

• Why detect shift: The shift key is frequently used as a sprint or sneak control in many (non-Scratch) games. It is easy to press, since it's very big, and people are somewhat used to using it in games. The shift key is also needed in virtually any word processor (or text input) program, for inputting uppercase letters.

• Why detect control: Another easy to press modifier key. This would work nicely in text editors; for example, if (control key pressed) and (a key pressed), then select all. However, the control key is often used for browser shortcuts, such as Control + W to close a tab. So projects which depend on the control key might only work fully on browsers which don't use control for keyboard shortcuts, such as any macOS browser, but not most Windows/Linux browsers.

• Why detect delete/backspace: These obviously are needed for any text editor program. Otherwise, there's no key to delete characters! Also, the backspace key is used for many more-graphical programs, such as a vector editor where backspace deletes a selected object. (Currently, projects like that have to resort to less intuitive keys, like X.)

• Why detect enter: Enter is generally used as a confirmation key. For example, in a custom prompt program, the enter key would be used to confirm an input. Or enter could be used to confirm changes in a simple settings screen.

Some other useful keys: escape, for getting out of custom dialogs or pausing a game (though potentially difficult to implement if escape also exits fullscreen), and page up/down and home/end, which are probably useful for custom scrollbars.

[towerofnix]

A scary suggestion:

What if passing a number to the "key pressed" block simply returned if the key whose key code matches that number is pressed? This would make the "key pressed" block virtually completely powerful, without cluttering the dropdown with keys rarely used such as page up/down. Currently, projects like griffpatch's Word Processor have to actually embed those very ASCII characters right into the string inputs of the "key pressed?" block. (So you get blocks like "key \n pressed?", where \n is literally a newline character.) This is extremely counter-intuitive and definitely a hack (it requires manually editing the JSON of the project, of course). Adding in general support for detecting keypresses based on a key code would solve this (you'd do "key (0 + 13) pressed" or "set (new line) to (13); key (new line) pressed?" instead).

The only problem with this: it's secret behavior, and unclear to someone who isn't expecting it :) - This could be amended by adding information about it to the help screen of the "key pressed?" block, but I'm not sure how you're supposed to explain to someone who's only programmed with Scratch before that passing in a number should make it check if some key code is pressed, according to an arbitrary dictionary of key codes to keyboard keys. Perhaps link to http://keycode.info/? That's a fairly easy-to-use tool.

[AmazingMech2418]

@towerofnix Maybe instead, there should be another block that is <key with code () pressed?>.

[apple502j]

I never agree because TABLES DON'T HAVE THESE KEYS. See LLK/scratch-gui#1354

[apple502j]

@amazinigmech2418 if you want, it should be "extension".

[towerofnix]

@apple502j Sure, tablets don't have these keys, but they don't have any other keys either. Would it be wise to completely remove the "key pressed" blocks, for the sake of having "computer" projects be 100% supported on tablets?

[AmazingMech2418]

@towerofnix Then many projects would no longer work. You can just make buttons to make a mini keyboard inside the project for mobile devices.

[AmazingMech2418]

@apple502j Why would it be an extension? You'd have to make a full new block for the menu to work.

[apple502j]

@amazinigmech2418 some blocks which are difficult to understand moved to extension, like pen. keycode block should be there.

[AmazingMech2418]

@apple502j You're not understanding what I'm saying. I'm saying to just add those characters to the menus.

[thisandagain]

This has some serious implications on accessibility with screen-readers (which often use modifier keys as listed above for navigation).

[AmazingMech2418]

@thisandagain https://wiki.scratch.mit.edu/wiki/Panther_(Scratch_Modification) talks about a mod with the keys I suggested in this issue, so that shows I'm actually not the first person with the idea. You could possibly use the code for that to also get the key codes (not e.keyCode in JS, but the text code for the keys like what would be needed for JSON editing in 2.0).

[AnmAtAnm]

@thisandagain, I don't see this as an accessibility issue, as long as a accessibility navigation takes precedence over the in-project events and authored behavior. This is exactly like browser keyboard navigation taking precedence over authored behavior.

Compare the request with the video or microphone blocks. Not all users/devices have that hardware, but we still have those blocks and allow users to make projects that use those features. In the keyboard event case, we have a small minority of users who can interact fully with projects that use that feature.

I personally like the ability to drop a block into the key pressed drop down. The KeyboardEvent.code is the obvious reference of allowed keys. It adds advanced support without cluttering the menu options seen by all users.