Add support for ButtonInput<Key>

[kristoff3r]

Objective

While KeyCode is very often the correct way to interact with keyboard input there are a bunch of cases where it isn't, notably most of the symbols (e.g. plus, minus, different parentheses). Currently the only way to get these is to read from EventReader<KeyboardInput>, but then you'd have to redo the ButtonInput logic for pressed/released to e.g. make zoom functionality that depends on plus/minus keys.

This has led to confusion previously, like #3278

Solution

Add a ButtonInput<Key> resource.

Testing

Modified the keyboard_input example to test it.

Open questions

I'm not 100% sure this is the right way forward, since it duplicates the key processing logic and might make people use the shorter ButtonInput<Key> even when it's not appropriate.

Another option is to add a new struct with both Key and KeyCode, and use ButtonInput with that instead. That would make it more explanatory, but that is a lot of churn.

The third alternative is to not do this because it's too niche.

I'll add more documentation and take it out of draft if we want to move forward with it.

[github-actions]

It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note.

Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes.

[alice-i-cecile]

My initial stance on this as SME-Input is that a) we should do this and b) we need to be extremely careful about docs here.

[Shatur]

Makes sense to me.

[IceSentry]

I think this PR generally makes sense, but I think to avoid any footguns the docs of KeyCode should point to Key and explain why they might want it and the reverse should also be done. I also think Key::Character should point to KeyCode to let users know they might want to use that one instead.

Maybe we should rename Key to LogicalKey? That I don't know, but treating Key and KeyCode on the same level makes sense to me.

[kristoff3r]

I think this PR generally makes sense, but I think to avoid any footguns the docs of KeyCode should point to Key and explain why they might want it and the reverse should also be done. I also think Key::Character should point to KeyCode to let users know they might want to use that one instead.

Maybe we should rename Key to LogicalKey? That I don't know, but treating Key and KeyCode on the same level makes sense to me.

Yeah definitely the docs need to be improved, I'll do that soon and take the PR out of draft when I'm done.

Key and KeyCode are both copy pasted from winit, so we shouldn't change the name unless we have a very good reason.

[kristoff3r]

@alice-i-cecile I added docs and release notes, let me know if you want more docs in other areas as well.

[alice-i-cecile]

I'm happy with the level of clarity here, and I think we should expose this.