Enter key ReceivedCharacter(13) not 10

[elbaro]

[repost from glutin-#1008]

In Linux pressing enter produces glutin::WindowEvent::ReceivedCharacter(13).
I think the correct keycode is 13 but correct char should be 10 in Linux.
Is this a bug or should I check for 13 and convert to 10?

[elinorbgr]

Is in on Linux X11 or Linux Wayland?

[francesca64]

I went ahead and tested all the desktop backends:
(Using hexadecimal makes this easier to Google)

Platform	Return	Enter
Windows	0x0D	0x0D
macOS	0x0D	0x03
X11	0x0D	0x0D
Wayland	0x0D	0x0D

0x0D (13) = \r
0x0A (10) = \n

I can confirm that directly using ReceivedCharacter to write to a file leaves me without any newlines, though Alacritty isn't affected by this, since it presumably does some sort of handling. Now, I'm not well-acquainted with the nuances of this issue, but it does seem like it's likely to surprise people, so I'd say it warrants deeper investigation.

[elbaro]

I am on X11. I wasn't sure if this is a bug or intended, but in either case, calling '\r' as a received char in linux seemed unintuitive.

A side question: I want to see the unicode input support in GUI crates. For now their textbox implementation relies on its window library's event system (e.g. simply appending new ascii char from winit). I think it is easier to implement IME support in winit than each GUI crate implements its own. Will winit support IME? If then, I guess IME will take care of CR/LF distinction.

[francesca64]

In what way does winit not already support IME? Have you tried building from master?

[elbaro]

Just tested master and it works. Great!
Does it mean my IME (fcitx) is sending '\r'?

[francesca64]

Alright, I did some digging, and I think I understand now. For historical reasons, the keyboard is always going to give us \r, so that's the value X11 gives us.

The current behavior seems like it will inevitably lead to application bugs, and it should be harmless to just always return \n as the result of inputs with the Return/Enter VirtualKeyCode (and \r\n on Windows). Though, I'm not sure if that's the best approach to take here, so I'd like to hear more thoughts from people.

This isn't an issue for GLFW, since they don't send Char this low in the range, so anyone using GLFW would have to make an active choice on how to handle the Key event for enter/return.

[elbaro]

'\n' or '\r\n' depending on platform sounds natural.

The current ReceivedCharacter(char) cannot represent '\r\n'.
Possible solutions are

1. ReceivedCharacter(&str)
2. ReceivedCharacter('\r') + ReceivedCharacter('\n'): not atomic
3. always use ReceivedCharacter('\n')
4. Introduce ReceivedString(&str) for multi-char input

[elinorbgr]

I'd add that in general regarding input handling, a single keystroke can generate several utf8 characters, So maybe it should be proper to replace ReceivedCharacter by ReceivedString altogether...

See for example the kind of code we have in the wayland backend, this is not ideal I think:

https://github.com/tomaka/winit/blob/42f0671531155a2a468de31f9b3ea545d29c4eb1/src/platform/linux/wayland/keyboard.rs#L71-L75

[edwin0cheng]

The situation for the macos backend is same as wayland :
https://github.com/tomaka/winit/blob/42f0671531155a2a468de31f9b3ea545d29c4eb1/src/platform/macos/events_loop.rs#L339-L342

And for Windows, it do not support utf8 str currently (but we should use WM_UNICHAR instead):
https://github.com/tomaka/winit/blob/eadd9a19b27ab3f6aa4904c5cb31726c5591cfd9/src/platform/windows/events_loop.rs#L475-L484

So i think we should replace ReceivedCharacter by ReceivedString too, since all platform can handle it easily.

[francesca64]

ReceivedString makes a lot of sense.
https://github.com/tomaka/winit/blob/eadd9a19b27ab3f6aa4904c5cb31726c5591cfd9/src/platform/linux/x11/mod.rs#L510-L516

@edwin0cheng

but we should use WM_UNICHAR instead

The situation looks more complex than that: http://archives.miloush.net/michkap/archive/2012/05/21/10308135.html
It seems like we should be handling both events.

[edwin0cheng]

@francesca64 Yes, we should handle both case. On the other hand, we have to handle WM_CHAR in utf-16 format too.

from https://msdn.microsoft.com/en-us/library/windows/desktop/ms646276(v=vs.85).aspx :

Remarks
The WM_CHAR message uses Unicode Transformation Format (UTF)-16.

[francesca64]

@jwilm since you're someone this directly impacts, what are your thoughts on the \n vs. \r situation?

[ArturKovacs]

While discussing the keyboard input API over at #753 I brought up this issue in the following comment: #753 (comment)

To summarize the discussion that followed, we decided to send \r for the Return key (Key::Enter in the proposal). To provide platform friendly line breaks winit would have to do some extra processing on the keyboard input, but some applications need to use line endings different from the platform native one, in which case the application would have to process the keyboard input anyways. For example a text editor might want to use Unix line endings for one file but Windows line endings for another. At the same time, sending \r for the Return key is what systems have been doing so we chose that as our designated universal indicator for line breaks.

[kchibisov]

\r is what should be used and is what expected by lots of tools. Keyboard API model we have change settled on \r.