Add layout selector for jsons with multiple layouts

[NCKiser]

For many boards, there are many layouts possible. It is not too difficult to make a json with multiple blocks in the "layouts" section for these different physical layouts.

Suggestion, when parsing the json, if there is more than one block in the "layouts" section, list them in the top bar to the right of the Branch selector, with the names for the layouts being pulled from the name of the blocks in the json.

[NCKiser]

Alternatively/Additionally, support choosing one of multiple boards that are all in the same repo? Not necessary, since boards/shields should have their own repositories in ideal conditions, especially if they are customer-facing repos.

[nickcoutsos]

This is supported in some form already, if I'm not misunderstanding your request. If your zmk-config repo contains multiple keymaps in the config/ directory the app will let you select which you want to edit. Ideally you'll have a matching <keyboard>.json file for each keymap, but if you have info.json (originally the only place I'd look for a layout) it can be used for the "default" keymap.

The layouts in your JSON file are meant to correspond to labeled zmk,matrix-transform nodes defined by the keyboard, and the editor will try to select an alternative if the keymap file specifies one in a chosen node, e.g.:

/ {
  chosen {
    zmk,matrix_transform = &my_other_layout;
  };

  keymap {
    ...
  };
};

That said, the editor doesn't allow for swapping layouts within the app. You can get the same result by treating them as separate keymaps but they'd have to be keymaps for separate boards, as you say. The naming conventions are pretty important from what I understand (which isn't a lot, I've been ignoring the details of the build system since I've started this project).

[NCKiser]

Okay, sounds like I need to do a bit more investigating. I will get back with what I find.
From what you are saying, the best way to do what I intend (selecting different physical layouts to represent in your Keymap Editor), is to have multiple transforms defined at the keyboard level and multiple <keyboard1,2,3,etc>.json in the config directory that match the name of those transforms?

[nickcoutsos]

Right. Here's the ZMK documentation on matrix transforms. So in your case the transforms would be defined in config/boards/shields/asymptote/asymptote.overlay and then in config/asymptote.keymap a user could use the chosen node I mentioned above to select an alternate layout.

In theory the app could have functionality to switch to a different transform and layout, but I don't think it's appropriate to present that in the selection UI as this would be a destructive operation.

[NCKiser]

I think we aren't quite on the same page, perhaps I haven't been too clear in my intention.
I have a shield that has multiple layout options, like split bars, arrow key layout, etc. They all have the same matrix and can use the same transform for the keymap itself. I was just wondering if there was a way to represent different physical layouts by selecting from a list different key placement json's, like the ones produced by your Keymap Layout Helper.

[nickcoutsos]

Ah, ok, thanks for clearing that up. I was thinking of how other keyboards use alternate transforms to handle things like 5 vs 6 column layouts -- where a transform would most likely be using a different arrangement and/or number of keys.

In your case I suppose technically different matrix transforms would amount to the same matrix and explicitly defining each one wouldn't serve much purpose outside of my tooling to auto-generate a layout from that (not relevant since you've already prepared the layouts). This may sound a little goofy but maybe the lowest-effort way to accomplish this in the app would be aliasing the singular matrix transform so that the app can differentiate between layouts as I described above.

So in `config/boards/shields/asymptote/asymptote.overlay' you'd have something like

/ {
  ...

  asymptote_a: asymptote_b: asymptote_g: default_transform: keymap_transform_0 {
    compatible = "zmk,matrix-transform";
    map = <...>;
  };

  ...
};

This creates a single matrix transform (which you already have) with 4 labels (default_transform, asymptote_a, asymptote_b, and asymptote_g) that can be used to reference it and a transform specified in the keymap's chosen node can be matched up with a layout in asymptote.json like we talked about before.

So the end result is:

• Only one shield is defined
• Only one matrix transform is defined (but with multiple aliases)
• Only one asymptote.json
• Three layout options available, selected according to the /chosen/zmk,matrix_tranfsorm value in config/asymptote.keymap

There would still be the manual step of a user modifying the keymap file directly to switch the layout initially.

[nickcoutsos]

Sorry if that's all stuff you're aware of already -- it sounds like maybe the one extra piece you're looking for is just a way to switch between layouts at runtime without necessarily making the underlying change to the selected matrix transform (even if the transforms are identical)? It's not impossible but I think the fact that it depends on knowing that the layouts are more or less cosmetic, and therefore "safe" to switch between dynamically, means it isn't something I can prioritize.