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

Feature request: Alt-Gr key labels #32

Open
chrissicool opened this issue Jul 17, 2023 · 1 comment
Open

Feature request: Alt-Gr key labels #32

chrissicool opened this issue Jul 17, 2023 · 1 comment

Comments

@chrissicool
Copy link

Hi,

keymap-drawer has the the following fields that show up for a key: tap, hold and shifted. Some European keymaps make extensive use of the Alt-Gr (aka. right ALT) key to add another layer of keys. These mostly include signs like @, , [, ] or |. See the AZERTZY layout, for example.

It might be beneficial to have some of them printed on the generated keymap. Using the hold field as an alternative is not a good option, since Alt-Gr is (like the shifted state) a tap field., which is additional to all the other fields which are already present. I propose to add another field to LayoutKey, maybe called alt. It could be printed on the right side of the physical key.

@chrissicool chrissicool changed the title Feature request: Alt-key labels Feature request: Alt-Gr key labels Jul 17, 2023
@caksoylar
Copy link
Owner

Hey, I had intended the shifted field to cover all such modifier scenarios -- for instance ZMK parsing assigns any mod-morphed binding to that field regardless of the modifier. However, from your AZERTY link I can see how you might want separate Shift/AltGr alternate functions, on e.g. the number row keys.

Currently, some workarounds can be:

  • Place both shift/altgr keys on shifted, e.g. space-separated
  • Make a "altgr layer"

I propose to add another field to LayoutKey, maybe called alt. It could be printed on the right side of the physical key.

This could be a solution although I am a bit hesitant to add more fields; especially with left/right fields it might be difficult to preserve clarity and not look too busy. It would essentially be constrained to 1-2 char values but that should be fine for your use case. I'll think about it and maybe give it a try to see how that looks, both outcome and implementationwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants