use setRawButtonDown/UpEvent

[pippinsmith]

Using setButtonDownEvent and setButtonUpEvent with non-US keyboard layouts sends the identifier from the keymap, not the scancode, this leads to some keys not registering at all (e.g. the "`" key between the esc and tab keys, on my azerty keyboard "²", reports as <` -> none "²"> when printing Ursina().win.get_keyboard_map(), resulting in no event being triggered)

When using the Raw versions, the event gets triggered with the scancode and therefore correctly reports ` to the input method

Since setButtonRepeatEvent('buttonHold') references a repeated Keystroke, this is not relevant there (it also does not have a raw version, and is not used for held_keys)

[pippinsmith]

see https://docs.panda3d.org/1.10/python/reference/panda3d.core.ButtonThrower#panda3d.core.ButtonThrower.setRawButtonDownEvent and https://docs.panda3d.org/1.10/python/programming/hardware-support/keyboard-support#raw-keyboard-events

[pokepetter]

This breaks key combinations, like Shift+Q to trigger the exit_button.

[pippinsmith]

whoops, lemme see if I can fix that then (tbh, personally not a big fan of how the combo key flow is written, but that's just my opinion ofcourse)

[pippinsmith]

@pokepetter got some progress but running into one last bump when it comes to self.accept(f'raw-{e}-repeat', self.input_hold, [e, True]) and self.accept('buttonHold', self.input_hold): the former of these 2 actually doesn't trigger at all, because "-repeat" apparently only applies to keystroke events, which by definition can't be "raw" in panda3d (see https://docs.panda3d.org/1.10/python/reference/panda3d.core.ButtonEvent and the inexistence of "T_raw_repeat", seeing "T_resume_down", makes me wonder if that's gonna give issues too though) where buttonHold triggers from the ButtonThrower, and is also not raw, so it uses the keymap of the OS and not the scancode. This then gets processed by input_hold which fully ignores the is_raw check (that doesn't apply either way) and then forwarded to input as + " hold".

Considering the input_handler doesn't use this for handling, and text_input uses it's own event (keystroke), can you advise on the correct way forward with this? (I'm unsure what the specific idea was behind input_hold)

Thank you for considering this potential enhancement for keyboard input (and input rebinding)