Feature request: Alt-Gr key labels

[chrissicool]

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.

[caksoylar]

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.

[magicDGS]

I am also really interested in this feature, as otherwise there is a very difficult way to implement non-US OS based keyboards that can be represented with keymap-drawer: for example, in my keyboard I have some Spanish symbols that I prefer to keep on the default key-bindings and not use a dedicated layer/combo to create them because they are not widely used. This is nice to visualize when you are learning a new layout, as sometimes muscle memory in normal keyboards is really strong that you don't really realize where they are, and then on a different layout it will cost a bit more (even more if the physical keycaps are completely blank).

Last but not least, I believe that having a new field is benefitial to help even with the css customization, as I am also finding quite difficult to style certain specific keys (although this is a different issue, but I believe that in the case of Alt and/or AltGr this will be easier to fix on this specific case).

At the moment, a language like Spanish with limited custom css and configuration looks like this for a qwerty-based layout with shifted+alt keys (separated by space), which looks quite busy (numbers and special chars are the most difficult to read):

And in the case of using key-sides it looks even worse:

Some proposals from my side are the following:

• Allow somehow a way to introduce in shifted fields spaces that translate to spans (as this can be at least selected by css): this can be similar as how the modifier_fn_map handles the keycode_combiner, which separates it on span to make it easier to style.
• Include an altgr field (from my pov, more in line line with how OS layouts handle the alt-graph, as there is usually no symbol in alt - at least for Windows) as already proposed by @chrissicool. This will be the best for international support, as this is kind of giving the non-US layouts the same capabilities as the US ones.
• Support something similar to the keboard-layout-editor, where instead of using properties such tap/shifted/hold the way to handle the labels are based on positioning within the key: top/center/bottom/front and left/center/right. This is also more flexible and also enable complex definitions.

@caksoylar - I can try to support with one of the options and contribute if you feel that this is a posibility.

[caksoylar]

I think I like the third option as a generic solution to this. Clearly there is demand to add more than three legend fields to the key for some cases, and the user can be responsible for ensuring clarity. I probably wouldn't add any support for parsing to emit the new fields or emphasize it in the docs as the main method, but the following could be fine:

• Add extra center/top/bottom aliases to tap/shifted/held fields
• Add new left/right fields (where you could use e.g. right for AltGr keys by convention)
• I still think corner fields like top-left are too much, so I'd omit them

If you want to work on above, I'd be happy to receive a PR.

[magicDGS]

I will need to get a bit more familiar with the codebase to contribute, but to do so I would like also some clarification of what right/left will mean then: only right and left from the center (tap) by default?

I will let you lnow when you tell me that part when I get started with the contribution, as I don't wanna block the feature if you or somebody else wanna work on it.

[caksoylar]

I will need to get a bit more familiar with the codebase to contribute, but to do so I would like also some clarification of what right/left will mean then: only right and left from the center (tap) by default?

Yes, I am imagining it to mean center-left and center-right. The right one would have e.g. text-align: right in its CSS, and they would be placed right inside the left and right edges of the box, centered vertically like tap and offset horizontally by inner_pad_w.

I will let you lnow when you tell me that part when I get started with the contribution, as I don't wanna block the feature if you or somebody else wanna work on it.

Sure, let me know. I don't think it would be particularly complicated unless something unexpected comes up. If you can't get to it soon let me know too, I can have a look.

[magicDGS]

I have started the implementation and a PR will come soon, as I found some problems with the alignment of the right label (probably due to skill issues, to be honest).

[caksoylar]

I'll close this since we now have left/right legend types in b701cef, so e.g. right field can be used for AltGr labels by convention.