Keymap key display improvements

[petejohanson]

Currently, ZMK Studio doesn't incorporate the fetched behavior metadata to influence the rendering of each key in the keymap display, and just attempts to map any passed first binding parameter as a HID usage.

Ideally, we should leverage the behavior metadata to make attempts at rendering things differently, e.g. behaviors with no parameters we might be able to report a suggested "icon" from the backend and render that on the keys, bluetooth behavior with multiple parameters could show different icon for each first param (select vs clear) and render the second profile index as a number next to the icon?

Lots to explore how to try to do this both nicely and generically for pluggable behaviors.

[xingrz]

I think, instead of providing display_name and icons for built-in behaviors, I would prefer to provide a neutral and unique ID, such as "zmk,behavior-key-press" instead of "Key Press", or "zmk,behavior-bluetooth/select-profile" instead of "Select Profile". The Studio frontend could then decide entirely how to display them, whether as text, icons, or otherwise. This approach would also make it easier to implement i18n in the future.

[petejohanson]

I think, instead of providing display_name and icons for built-in behaviors, I would prefer to provide a neutral and unique ID, such as "zmk,behavior-key-press" instead of "Key Press", or "zmk,behavior-bluetooth/select-profile" instead of "Select Profile". The Studio frontend could then decide entirely how to display them, whether as text, icons, or otherwise. This approach would also make it easier to implement i18n in the future.

This breaks the requirement that the frontend have no specific knowledge of the set of possible behaviors. We need to support folks building with third party/custom behaviors that aren't in ZMK main. That's the main reason we use the behavior metadata approach.

[xingrz]

Thanks for the explanation!

[krikun98]

Shifted keypresses should probably display the shifted symbol ($ for LS(4) and etc.).

[petejohanson]

Shifted keypresses should probably display the shifted symbol ($ for LS(4) and etc.).

That is also planned, but will need host layout info to display properly

[mknj]

I took a look at the code and the storybook integration is really nice.
Then i tried to modify the keyboard and realised that adding features is really hard as keyboard and HidUsageLabel are tightly coupled.

How about moving the text calculation out of the keyboard and have the keyboard Component simply render the given text and headers?

In principle it would replace the children property with a centerLabel property. Later it could be extended by bottom, left and right labels like in KLE.

I think this would make the visual keyboard easier to maintain and experiment with.

btw.
This is my keyboard rendered in kle

and this is the 3rd layer in zmk-studio, which totally makes no sense as most of these keys are acutally shifted

[mhantsch]

but will need host layout info to display properly

Why not start with an assumption of US-QWERTY as they are configured today with that mapping anyway. All the scancodes mapped in ZMK config files are based on US-QWERTY.

Support for other locales can come at a later stage. The remapping would then affect not only the display of the keys but also the scancode assignment (e.g. for Keypress behaviour).