Synthetic keyboard input #26271

What problem does this solve or what need does it fill?

Anything that simulates typing, such as a headless App test, an end-to-end test over BRP, has to build each KeyboardInput by hand. Each event needs a key_code, a matching logical_key and text, and Shift pressed around capitals and symbols. A real keyboard never needs this mapping, because the OS applies the layout and winit reports both values. Synthetic input has nowhere to get it, so every caller writes its own table or gets text wrong.

Bevy's own tests already do this:

• bevy_input_focus's key_a_message pairs KeyCode::KeyA with Key::Character("A") by hand.
• bevy_ui_widgets' text-input tests pass the logical key and the key code separately.

Note that the feathers virtual keyboard side-steps the problem entirely, but only inserting keys into an EditableText buffer - it does not generate KeyboardInput events.

What solution would you like?

A helper function for synthetic keyboard input: a small helper in bevy_input that names its layout:

• For a KeyCode (and whether Shift is held): the logical_key and text it produces.
• For a character: the KeyCode and whether Shift is needed.
• For a string: the sequence of KeyboardInput events that types it, with Shift pressed and released where needed.

It's for input whose author picks the layout, as a test does. Anything players see, such as an on-screen keyboard, takes its layout from its own key definitions.

It would support US layout only, stated in its name or docs. KeyCode follows the W3C UI Events "code" spec, which names keys by their US QWERTY position, so US is the layout the variant names already assume. The table would cover printable keys plus common named keys (Enter, Tab, Escape, the arrows). Other layouts are out of scope, and callers can still build events by hand.

Open questions

• Its name and location: KeyboardInput constructors, or a bevy_input::keyboard::synthetic module.
• Whether it should also cover the reverse lookup, character to key code, for on-screen keyboards.

What alternative(s) have you considered?

Having each user supply both the physical and logical keycode for every KeyboardInput.

The cost is volume, not difficulty: typing a string means one event per character, with Shift pressed and released around each capital or symbol. Every test suite writes that loop for itself. A middle ground would be to require both keys for single key events and derive only for typing a string, where the burden is greatest and US-layout characters cover nearly every test.

In practice, this means that the keyboard conversion table would still exist, but it would be in the client, not a server-side method.

@mockersf @ickshonpe