What is the status of key-events for unicode keys, if I may ask?
I’ve had a report that my KeyMapper module, which uses key-events behind the scenes, doesn’t accept keys like “ě”. And indeed, a quick check with an on-screen keyboard indicates that said character, at least, is not handled by key-events.
I found the following thread discussing the matter–there seems to be some indication that the set of events supported could be extended, but no clear indication that it was done. (Unless I missed it, which is very possible.)
There also seems to be no fitting issue in the GitHub issue-tracker.
(It is mentioned in the report linked-to above that such keys do work with raw inputs, at least.)
It’s firstly important that you don’t use individual button events for text input. It is impossible to handle text input correctly using key bindings (it won’t take into account things like dead keys and other text input methods), which is why we provide a separate keystroke event for that.
Secondly, to be able to bind any key on the keyboard, you need to use the “raw” events, like “raw-w”, “raw-s”, etc. These keys are bound to their position on the keyboard (as corresponding to the QWERTY layout) rather than what they are mapped to in the operating system. You can use base.win.getKeyboardMap() if you need to be able to map between the “raw” button and the corresponding mapped key (as it should appear in help text).
A side-effect of the above is that you automatically correctly map bindings like WASD to the equivalent on a user’s keyboard layout - preventing users from having to stretch their fingers awkwardly across the keyboard in order to be able to walk around.
I was wondering, then, why key-events exist at all given this–but I suppose that there are cases in which you want a command bound to a specific letter, and not a specific location on the keyboard.
So, I suppose that I’ll likely look into switching to raw-events, then!
[edit 2]
I forgot to respond to this:
Indeed, I believe that I’m not using key-events of this sort for any of my text-input. So that, at least, doesn’t seem to be worry! ^^;
[/edit 2]
Thank you for the response.
That said, outside of the purpose that I have here, is it perhaps worth expanding the key-events to include unicode letters? After all, there may be devs who want to bind commands to such letters.
Yes, it can be argued that non-raw key events aren’t very useful—but prior to the existence of raw events, they were the only thing we had.
Of course it would be easy to add an event for the ñ key on a Spanish keyboard, or the ø æ å on a Norwegian keyboard, and we could even add all the keys on a Russian keyboard. But in theory there are over a million possible characters that can be mapped. Do we add individual events for, for example, all of the many thousands of Chinese characters in existence, that are all typed by combining multiple keystrokes? What about dead keys (keys that don’t produce a letter, but modify subsequently typed characters)? What about the ∞ ʃ ² that I have mapped to key combinations in my .XCompose file?
I don’t know the right answer to these questions, but to me it does underscore the unsustainability of hardcoding key mappings based on the produced unicode codepoint, as opposed to some symbolic value that corresponds to the scancode generated by the USB controller (which is what raw-x does).
Thats a good point. Its just a noob trap imho. I think it should be reworked so it throws ASCII keys because raw has this extra hurdle when you want to use it with modifiers. So this could be for that purpose.
Hmm… Could it be, at least in part, solved by having key-events internally call raw-events and then use the keyboard layout to report an event constructed from that?
It wouldn’t cover everything, but might it cover at least a bit more? And further, without having to hard-code those elements within Panda.
When you say that it should throw “ASCII keys”, do you mean something such as I described a few paragraphs above in this post, or something else? I’ll confess that I’m not quite sure of what you’re suggesting. ^^;
What I suggest is that it should be the same raw-key is but without the raw- prefix and keep the functionality for modifiers. Right now theres no shift-raw-key or raw-shift-key or raw-shift-raw-key.
@rdb
And why cant panda read the keyboard layout and then throw the event with the label for the key?
