possible fix to the linux e,s,r bug in text editor. #2334
Conversation
|
I have had 2 different Linux users try a test compiled ZIP of this PR, and both reported that it fixed the problem. I also tried it on Windows to verify that it still works on Windows after the change. I say it's good enough to merge based on that, but someone else should merge it, unless I decide it's okay to abandon that rule because other devs have no time for the mod anymore. |
|
Can one of the devs using Linux just give this a quick once-over and put an official (as in reviewer) stamp of approval on it so I can merge it without breaking our "don't merge without second person review" rules? ^Tagging @lucaelin and @evandisoft on this. Either one of you would do. |
|
I'll check this out after I set things up to work on multiple branches at a time. |
|
It Works! Thank you! And the code changes don't raise any alarms to me. (Since you've tested it on windows.) |
Fixes #1071
So it was a bug in kOS, but a bug that got hidden by Unity's order of handling input events on Windows.
The bug - While I was only reacting to the E, S, or T keys when "control" was pressed, which is correct, I was still "consuming" those keyboard events unconditionally whether the control key was down or not.
Why it didn't affect Windows: Apparently in Windows the generic Textfield GUI widget from Unity's IMGUI (the thing the text editor really is), got first dibs on the keyboard events before my code did, so my code never got to see key events that the Textfield used, so S, E, and R never got seen by my code unless they were accompanied by special ctrl- or alt- keys. Vanilla S, E, and R keys never reached my code - the Textfield got them first and consumed them.
On Linux they seem to be queued in the opposite order so that my mistaken consuming of the key happened before the Textfield got to see it.