zmk-viewer Add support to templates

I've created a template system to support custom keyboard layouts that are not available in QMK Toolbox as suggested in #2.

The template uses YAML syntax and is quite simple with a few keywords available, it can be improved with some feedback.

This is an example template for S'mores Clog keyboard:

keyboard:
  name: The Clog # Optinal, currently not used
  mirror: true # To create a split keyboard declaring only the first half
  columns:
    - keys: 1 # Number of keys in the column
      step: 3 # Offset from top
    - keys: 2
      step: 2.5
    - keys: 3
      step: 0.5
    - keys: 3
    - keys: 3
      step: 0.5
    - keys: 4
      step: 0.5
  keys: # To target specific keys that need more personalization. 
    - column: 6 # Thumb key
      row: 2
      step: 0.9
      h: 1.7 # Height of the key. there's also 'w' wor width

When running the command zmk-viewer generate clog --template theClog.yaml this is the image produced: imagen

It's also possible to use the template to parse .keymap files using this syntax: zmk-viewer generate clog --template theClog.yaml -f clog.keymap: imagen

Currently, the template is generated from left to right & top to bottom while the keymap is parsed top to bottom & left to right. This generates some inconsistencies in weird layouts when the keys are formatted to look like the keyboard, like in The Clog:

        MAIN_layer {
            bindings = <
                            &kp W      &kp E       &kp R        &kp T            &kp Y     &kp U      &kp I           &kp O
          &kp Q &kp A       &kp S      &kp D       &lt SYM F    &kp G            &kp H     &lt SYM J  &kp K           &kp L        &kp SQT        &kp P
                &mt LSHFT Z &mt LALT X &mt LCTRL C &mt LGUI V   &kp B            &kp N     &mt RGUI M &mt RCTRL COMMA &mt RALT DOT &mt RSHFT FSLH
                                                   &lt BT ENTER &lt NAV SPACE    &sk RSHFT &kp BSPC
            >;
        };

I'm not sure about how ZMK parses .keymap files, if they take in account this order or not.

Apr 03 '22 10:04 MrMarble

Hi! Cool project!

I've done some tangentially related work to parse a zmk keyboard's layout, again to handle a situation where the user doesn't want to do the work manually. You'll want to look at the matrix transform in the .dtsi (or else .overlay?) file, e.g. clog.dtsi.

It's an interesting pickle... zmk's keymap bindings array is inherently row based because, well, it's text, so columnar keyboards tend to be represented as ortholinear for ease of editing. Your layout description is explicitly column based (respect!) so you would need to define some mapping between the two.

In my version I parse the locations of the RC(...) values in the map to roughly ortholinear row/column positions. It has to fudge things to figure out what column is most appropriate for keys in row-staggered layouts and has no way to guess at different key sizes, but the intention is to have the user go back and tweak the layout as appropriate (maybe not sufficient for your use case).