Open aarzilli opened 8 years ago
We could do something similar to https://git.merproject.org/mer-core/qtbase/blob/dfe853bff90444edf92a993e391df853780c9e8d/src/plugins/platforms/windows/qwindowskeymapper.cpp#L539 (I just googled), if we want to return 'c' on windows.
Leaving for to @crawshaw and @nigeltao to decide.
Alex
I have noticed that there are also other discrepancies: CodeReturnEnter gets '\r' on windows, '\n' on linux; CodeTab and CodeDeleteBackspace return '\t' and '\b' on windows but -1 on linux.
Let me think about it...
I think that all platforms should behave the same. Specifically:
Ctrl-A should have Rune == -1.
CodeReturnEnter has Rune == '\n', especially as you can't set Rune == "\r\n" (a string) on Darwin.
CodeTab should have Rune == '\t'.
CodeDeleteBackspace (and CodeEscape) should have Rune == -1. I wouldn't expect a text editor to want '\x08' or '\x1b' runes inserted into the text.
WDYT? I'm happy to do the Linux and Mac changes if there's consensus.
WDYT?
I don't use this package myself, so I am fine with whatever you decide. We could always change our mind once we know more.
Alex
I'm ok with this, but:
Ctrl-A should have Rune == -1.
what happens if the user presses Ctrl+<Some key that doesn't exist on a US keyboard>?
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.7 linux/amd64 go version go1.7 windows/amd64
What did you do?
Open a shiny window, log key events received, press ctrl+C on the window.
What did you expect to see?
I expected the value of event/key.Event.Rune to be the same on linux and windows
What did you see instead?
On linux ctrl+C produces the rune 'c', on windows 0x3 is reported instead. This isn't limited to 'c' all ctrl+key combinations produce different results on windows and linux. I think that the value of Rune should either be the same across platforms or always set to -1 when ctrl is pressed.