Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-Qwerty keyboards broken with current defaults #18

Closed
g2p opened this issue Sep 10, 2019 · 8 comments
Closed

Non-Qwerty keyboards broken with current defaults #18

g2p opened this issue Sep 10, 2019 · 8 comments
Labels
type:bug Something isn't working

Comments

@g2p
Copy link

g2p commented Sep 10, 2019

I figured out that I need to enable the winit feature to get proper key mappings on my non-qwerty keyboard.
Maybe this should be documented, or enabled by default.

@cloudhead cloudhead added the type:bug Something isn't working label Sep 10, 2019
@cloudhead
Copy link
Owner

Do the default key bindings usually work for you in other software? Can you give an example of what's not working and what layout are you using? Thanks.

@g2p
Copy link
Author

g2p commented Sep 10, 2019

I'm using azerty.
Almost all software works by default, everything follows the keyboard layout, which is great except for the occasional game that uses a hard-coded, non-remappable WASD.
Here's a map for perspective.

@g2p
Copy link
Author

g2p commented Sep 10, 2019

The first thing I tried was to enter command mode, I got zoom-in instead, and had to grep the source to find what was going on.

@cloudhead
Copy link
Owner

Hmmm, there's two ways to solve this that I can think of, but none are ideal:

  1. Support specific layouts out of the box, eg. qwerty, qwertz and azerty, and have the user set the layout they want to use.
  2. Change the way inputs are processed, however this might mean that you can't have hold/release behaviors on keys other than shift/ctrl/alt. So you can't have for eg. "hold e to switch to erase mode".

@g2p
Copy link
Author

g2p commented Sep 11, 2019

Could you start by blessing winit over glfw?
Having two divergent ways of handling key bindings is bound to break expectations.
I haven't had any trouble once I enabled the winit feature, and if it starts behaving strangely grepping for accesses to the scancode field would make it very easy to pinpoint the issue.
Also, by keeping interactions close to vim, I don't think you will be required to do anything that doesn't localize.

@cloudhead
Copy link
Owner

Could you start by blessing winit over glfw

Unfortunately not - winit has significant problems on macOS. I’m not sure actually why the two handle keys differently - potentially there might be a way to have winit’s behavior in glfw. I’m looking into that now.

@cloudhead
Copy link
Owner

I pushed a change to master that should fix this with glfw. Do you want to give it a try? You won't be able to map all keys on the azerty layout, but it should work for all keys accessible without 'shift' on the qwerty layout.

@g2p
Copy link
Author

g2p commented Sep 11, 2019

I tried it, it works fine.
Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants