davidgiven / wordgrinder

A word processor which gets the hell out of your way and lets you get some work done.
http://cowlark.com/wordgrinder
979 stars 61 forks source link

Keyboard shortcuts on international keyboards in X11 mode #214

Closed kbarni closed 6 months ago

kbarni commented 1 year ago

xwordgrinder (on Linux) uses the keyboard shortcuts according to the US keyboard layout. So on my french (AZERTY) keyboard the shortcut to quit is ^A, the undo is ^W etc. On german (QWERTZ) layout ^Z and ^Y are switched.

The ncurses version is behaving as expected.

davidgiven commented 1 year ago

Do you mean that on the German keyboard, you have to press the Control plus the key with the Y on it for undo? The one bottom left next to the | key?

If so, that's very weird, and probably caused by GLFW being helpful. I'll have to find a way to stop it.

kbarni commented 1 year ago

In fact my code wans't merged in the master branch.

currently the needed modification is:

keyboardQueue.push_back(-(((unsigned int)(glfwGetKeyName(key,scancode)[0]) - GLFW_KEY_A + 1) | VKM_CTRLASCII));

at line 77 in file src/c/arch/glfw/main.cc

davidgiven commented 1 year ago

Oops, that got lost in the recent refactor.

Looking at the code, doesn't the same fix also need doing to ALT keys? I've made the change in https://github.com/davidgiven/wordgrinder/tree/b214; PTAL?

kbarni commented 1 year ago

I didn't apply it to ALT because currently there are no alt-based keyboard shortcuts. But it's a good point.

The fix still doesn't work, as getKeyName converts the key to char, so it's not GLFW_KEY_ anymore.

If you keep this way, you need to change line 83 (and 130) to:

if((key >='a') && (key<='z'))

...but I think it's quite hacky. The key variable is a char for A-Z, otherwise it's a GLFW_KEY_....

I would rather keep my solution above (converting it at the moment of pushing it to the keyboard queue).

davidgiven commented 1 year ago

ALT shortcuts are used to open menus --- e.g. ALT+F is equivalent to ESC, F. Except, the former goes through the key_cb (and so receives a scancode) and the latter through character_cb (and so receives an ASCII key). So, they don't get remapped and therefore won't (or at least shouldn't) work on a non-US keyboard layout.

Regarding the GLFWKEY vs char values: I did check, and GLFW_KEY_A..GLFW_KEY_Z have the values 'A'..'Z', so that should be compatible.

kbarni commented 1 year ago

Yep, that's it ! In fact the captured keypresses are treated as uppercase, and getKeyName transforms them to lowercase.

So key is transformed from 'A' (GLFW_KEY_A) to 'a'. That's why the condition wasn't working.

davidgiven commented 1 year ago

Updated --- I think you're right and I shouldn't be mixing keycodes and ASCII characters.