cursor keys "Top" and "Right" move the cursor in the opposite direction under Linux about bonzomatic

[BetaSoftCologne]

in main.cpp, around line 460, I made a change to the call of mShaderEditor.KeyDown like so:

        if (Renderer::keyEventBuffer[i].scanCode)
        {
          // TODO: https://github.com/Gargaj/Bonzomatic/issues/144
          int sc = Renderer::keyEventBuffer[i].scanCode;
          mShaderEditor.KeyDown(
            Renderer::keyEventBuffer[i].character < 128 ? sc : iswalpha(sc) ? towupper(sc) : sc,
            Renderer::keyEventBuffer[i].shift,
            Renderer::keyEventBuffer[i].ctrl,
            Renderer::keyEventBuffer[i].alt,
            &consumed);
        }

[blouze]

The quickfix worked for me. Giving the proverbial test ride thanks to you @BetaSoftCologne !

[Gargaj]

@PoroCYon

[PoroCYon]

I can reproduce the issue, but, this isn't Linux-specific:

Adding a printf in the GLFW key callback shows that GLFW is able to distinguish between these four keys, and that the equivalent Scintilla key values are set. Ergo, it's not a platform thing.

However, this code here happily turns scancode 301 (up) into 300 (down), and 303 into 302, while leaving the other two untouched. Unicode codepoints 300 and 301 (U+012C and U+012D) happen to be 'Ĭ' (I with breve) and 'ĭ', respectively, 302 and 303 are 'Į' and 'į'. I very much doubt this is intended.

So I see three options:

• Check for ascii characters in the scancode, and only convert to uppercase in that situation. This mightn't be desirable for some keyboards.
• Add an extra flag to the key input buffer to tell the buggy code to only convert characters when that is set (basically bNormalKey here), but this will require testing for all platforms.
• Always convert to uppercase in all the platform-specific code (GLFW is currently converting to lowercase??)

Any preference, @Gargaj ?

[BetaSoftCologne]

Same here. My box:

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.5 LTS"

[BetaSoftCologne]

I made it work for me with a quick hack, but it made we wonder of the purpose of scanCode in general. Especially since a) there is also character which I assume contains the character (aka code point) of the key pressed and b) scanCode is used in comparisons as if it also contained a code point, like in line 453:

if (Renderer::keyEventBuffer[i].scanCode == 292 || (Renderer::keyEventBuffer[i].ctrl && Renderer::keyEventBuffer[i].scanCode == 'f')) // F11 or Ctrl/Cmd-f

I assumed that scanCode contained something like the key-number or so, not the character, but that's apparently not the case.

[blouze]

$ cat /etc/os-release 
NAME="Linux Mint"
VERSION="19.2 (Tina)"
ID=linuxmint
ID_LIKE=ubuntu
PRETTY_NAME="Linux Mint 19.2"
VERSION_ID="19.2"
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.linuxmint.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
VERSION_CODENAME=tina
UBUNTU_CODENAME=bionic

Same. @BetaSoftCologne can you explain how you fixed this? Or should I wait for a PR, I really wanted to try this...