How should the Kha/Kinc Keyboard work?

[Sanva]

Hi!

I'm trying to help improve the situation with Kha/Kinc keyboard across targets — I'm really interested in Android and Linux right now, and I knew nothing about low level keyboard input just a few weeks ago, and also I'm in my free time (like most, I suppose), so I can't promise anything really... but, the thing is that if I try, I will need some direction about how things should work.

Take for example Kode/Kinc#480 — there it is stated:

If you attempt to input the character '@' on a standard US keyboard, you need to hold the Shift key and press the number 2.

• On Windows, this results in Krom calling the onKeyDown listener with key code 50, and onKeyPress with the character '@'
• On Linux, this results in Krom only calling onKeyPress with the character '@', but not onKeyDown

Isn't that really a couple of misunderstood bugs?

The Linux thing was clearly a bug, but to me it looks like the fix shouldn't be to make it behave like Windows, because it looks like a buggy behavior. If you just think about 2 + Shift it could kind of work... that @ thing is in the 2 physical key... But, what about some key like 4 in numerical keyboard/keypad? It is both the 4 (keypad 4, not the regular 4) and the left arrow (again, the keypad one, not the regular one), so just sending a keyDown/keyUp event with the main key (keypad 4 in this case) wouldn't allow client apps to know what is really happening — moreover because, generally speaking, keypad 4 is something you want to use with keyPress and the left key is something you want to use with keyUp/keyDown [1] .

Also, the real Linux bug appears to me that was just a missing translation between @ in XKB and @ in Kha/Kinc — just something like this commit [2] but with a translation for XK_at to KINC_KEY_AT. Refixing it that way would also imply the recovery of the ability to distinguish between upper case and lower case alphabetic keys in the keyDown/keyUp part of this complexity, which I don't know if would be desirable. Also, accepting this would imply what the current (?, I'm not really sure, I didn't use Windows since years ago [3]) Windows behavior is not correct.

The summary of this question would be: Is there a reference implementation today that other targets should follow? The Windows one, maybe?

Bonus: Another thing will be Unicode input, but at least initial tests in some of my devices show that it is doable in Linux and Android, at least for basic Unicode (things like ł¶ŧ←↓→↑øþæßðđŋ).

[1] I think that is related to armory3d/armortools#713 .
[2] Kode/Kinc@a4d3b39
[3] I'm thinking about installing Windows in some device, to keep improving my knowledge about Kha/Kinc, mainly, but I don't know when, too much things to do and not enough RAM to do it all at the same time 🤣

[RobDangerous]

Windows behavior looks correct to me. keyUp/Down are not for text input, that's what keyPress is for and that should also support unicode, at least in theory.

[Sanva]

So, now that I have a working Windows virtual machine where I can build and test Kha apps, let me elaborate on Windows keyboard problem, since I don't really know if I've expressed myself properly in my first message — probably my communication error was about exemplifying using an example where Windows is indeed working as expected...

Please, take into account that I'm using a Spanish keyboard.

I can see that there is a concept of key (keyUp/keyDown) that is different from a character (keyPress), and:

1. In a basic case, for example, a char like a or A corresponds always to A keyDown. I can even press Ctrl + Alt + e to get € char and E keyDown — that's the physical key where we have the € symbol.
2. Also with regular numbers, I can press Shitf + [1234567890] to get !"·$%&/()= chars and 1234567890 keyDowns.

↑ Those two points looks consistent with each other to me. But with other keys:

3. If I press ' (right to 0 in my keyboard) I get ' char but OpenBracket key. If I press ñ I get ñ char but BackQuote key. With < I also get the correct char, but Unknown keyDown — and Kinc does have the concept of < key, KINC_KEY_LESS_THAN, working fine in Linux at the moment in my system.

4. With the keypad things work in a different way than in point 3 above. Where with those keys the implementation tries to use something like a physical key, with the keypad it's using the virtual key. So, if I press for example 0 with NumLock activated, I get 0 char and Numpad0 keyDown, but if I press 0 with NumLock deactivated I get no char and Insert keyDown, even when it is the same physical key.

I think that the behavior in point 4 is the correct one, whereas the behavior in point 3 is wrong. I know nothing about the capabilities of the API used in Windows, but I do know that this can be fixed in Linux (and I think I can), and I think it can also work right in Android.

So, should I open a bug in Kinc exposing the problem with Windows?

And, more important to me at this moment, since I intend to fix the problems in Linux and Android [1]: Should we consider that, if possible, Kha should give keyUp/keyDown events with the KINC_KEY_* constant corresponding to the physical keyboard key without the regular Shift nor Ctrl modifiers (but with NumLock or other applicable modifiers) using the current aplicable system locale?

[1] Not in Windows — if I'm right and point 3 is determined to be a defect/problem — because it looks like there are more contributors there and because I know almost nothing about Windows.

[RobDangerous]

keyUp/keyDown are not supposed to take care of language specific keyboard layouts - unless you find an easy method to do that across all platforms and all languages. I don't even know how Asian keyboards work.

[Sanva]

unless you find an easy method to do that across all platforms and all languages

Looks doable in Linux and Android — I'm asking for help with Windows.

I don't even know how Asian keyboards work.

I'm trying, to make this work as better as possible, if I can, but it looks like it is a complex theme — that's why I'm taking the effort of testing across systems before making changes, and trying to understand what are the desired behavior.

So, if the desired behavior is known to me now, should I infer, reading your answers, that a pull request removing for example the constant KINC_KEY_LESS_THAN, since it is not a physical key in a standard US keyboard, would be desirable?

[RobDangerous]

No, you should infer that we either put the time in to come up with a complete and consistent cross-platform and cross-language solution or just leave the code as it is. Otherwise we will just break existing code without really improving anything.