Hello everybody. I am working on a console for my gui library and i wanted to pipe the input from the keyboard to it and handle the stream directly inside the console. However it seems that when i press enter (the new line key, in french it’s “entrée”) i only got one event from the input manager, with the char code 13.
This code is the carriage return code (\r).
But there is no new line (\n).
I wrote a test case but i forgot it at home (stupid me). Well, it’s a complete empty application (there is nothing visual) with only in the simpleInitapp something like that:
And it’s enough to see a 13 (then a zero, when released) when you press the new line key.
I don’t think this problem comes from java (i’ll grab the code to display key events in java+swing this night and test it tomorrow).
From my point of view there should be either two event (one with \r and one with \n) or a method in the keyevent to get “additionnal” char linked to the event (and only one event).
As i am writing these lines i wonder how directional keys are handled from this point of view. Is it possible to access the ansi key sequence ? (27 followed by “[A” etc)
Same question for the \b associated with the delete key ect.
P.S.: i can detect the “enter” key event and handle it specifically. But it will not let me flush a file into my console or, more generally, let people do ascii gui in the old-fashion way.
The enter key is only one key code and it will be a carriage return because that’s what the ‘return’ key means.
You have to process these events yourself and add whatever line endings you prefer yourself. For example, on Macs it will often trigger a completely different key code for ‘return’.
I know that it’s different on linux and mac. But i expected the rawinputlistener to receive … raw inputs ? i.e. \r\n on windows, \r on mac and \n on linux (not sure for mac).
It does. It receives the actual key code from the keyboard. Any character associated with that is convenience filled in on some level by the operating system. It’s lucky that it works for characters.
For everything else like enter, carriage return, backspace, etc. you have to capture those key codes (not characters) and process them specifically.
Ok i’ll do that … but first i’ll dig a bit into jme to find how the inputmanager gets these keys in a first place. Maybe that the information i want is already there (and it’ll avoid a decode/encode/decode/encode/decode/encode … )
(shrug) Of the dozen or so console keyboard handlers I’ve written in my career of 25 years or so… I’ve always had to handle enter and backspace specifically for reliable behavior.
I don’t really understand the decode/encode/decode/encode/decode/encode part. It’s one if statement in your key event processor.
the decode/encode thing is because is you do all the path between my finger pressing a key and the software using it you’ll find a lot of transformation, and sometimes transformations to invert the previous one.
For example i found that a lot of program have problem with azerty keyboards (or qwerty). And they have even more problems with less usual keyboards.
The root of the problem ? If you have a character in a game that is keyboard controlled you want it to move forward when “the key under this finger is pressed”, and you don’t care about the value of this key. So, what are you gonna do ? Just create a mapping that will associate keycode to x/y position on the keyboard. Yes, you are doing work to revert the key mapping.
And if someone try to create a lineedit on top of your library and you don’t expose characters it will just re-do the mapping.
And each layer is a source of bugs and slow the program.
i think that beneath the inputmanager there is already several of such layers. If i add something that detect the backspace/return and so on, i’ll just add one layer. I’ll add one layer to transform the directional key into a key sequence (escape followed by [ etc), and an other one to transform this information into a movement of the cursor in the virtual terminal. decode/encode/decode/encode …
The key code is ‘the real thing’ that the keyboard driver is sending. It’s the lowest level. The character is added later… your keyboard has no idea what the character is for a given key. 0.
So, if( keyCode == K_ENTER ) is the lowest level check you can do. You’ve bypassed almost all interpretation at that point.
The character code, on the other hand, goes through all kinds of interpretation since it keeps track of the state of control keys, shift keys, capslock state, numlock state, alt keys, etc… It’s the very highest level of interpretation you can possibly get.
So in the end, if you want to know “did the user press the enter KEY?” Then using the character is the exact worst way to do it from a ‘how many layers will screw this up?’ standpoint.
Just an FYI, LWJGL3 actually integrates with the system’s IME (input method editor) which allows jME3 to receive actual characters as opposed to having to convert key codes into characters which is completely unreliable when it comes to typing Asian or accented characters.
About Chinese characters I don’t know, since the Chinese people on the other thread did not reply to my post.
So I wonder what LWJGL3 will add on top of that.
Btw, TestBitmapFont.java was a nice inspiration for my SimpleConsoleAppState. It’s part of that tutorial game and really works nice for all console commands that I needed so far.
thanks pspeed but … i am a computer scientist, i know all of that (master 2, security).
But you know that sometimes you don’t have access to the low level, and accessing that level require actually higher authorizations.
And i am maybe wrong but i kind of remember that the information sent by the keyboard is a position (not a code) and this position is translated into a character via a map (the one we set with setxkmap).
I didn’t wanted to detect the enter key but only implement a terminal widget that will handle input like described here http://man7.org/linux/man-pages/man4/console_codes.4.html
and after that pipe the input from the keyboard to this widget when it has focus, and voilà.
So i implemented the “\r” comportment (go back to the beginning of the line) and got a bug because there was no line feed (\n).
I kind of fixed all of that and the development of the widget is now ok (i even started to implement a terminal with commands that use this console).
@Momoko_Fan: nice. I worked a bit with SDL before and they went through problems making them change things between sdl1 and sdl2. I also worked with X11 (trying - with success - to create a gui library with zero memory leak) and the key resolution was a pain in the ass.
@Ogli: yes, accents are fine (and as i am french i use them often when i test my program). That was not the problem, my question was NOT about multi-byte characters but about multi-character keys. For example if you type an arrow key in some terminal in linux (not all of them) you’ll get things like “[[A”. (This is because the key actually send several character in the input, and it’s only the short time between them that makes them a single key and not esc then [ then A).
You can easily find informations about that, the key words are “ansi escape sequence”.
