• ansi
• iso

I'm not sure if this should be generic tags as those are sometimes layout-dependent (i.e. the zeal60 supports either). Or should a keyboard which can have both have both tags?

@Sebb767 Absolutely. But that's why both should/would be included if the board supports both.

Part of the reasoning for this is so we can use a wizard like interface for the QMK Configurator and narrow down boards. Because right now, we have about 200 boards in the main folder. And that doesn't count handwired stuff, nor subfolders like clueboard.

Also, talked about using something like:

{
    "tag_categories": {
        "stagger": ["ortholinear", "row-staggered", "columar-staggered"],
        "layout": ["ansi", "iso", "ortholinear"],
        "percentage": ["40p", "50p", "60p", "65p", "66p", "75p", "100p"],
        "formfactor": ["tkl", "fullsize", "1800", "40p", "50p", "60p", "65p"]
    },
    "tag_descriptions": {
        "ortholinear": {"description":"Keys laid out in a uniform grid with no stagger"},
        "row-staggered": {"description":"Keys laid out with the rows offset from each other"},
        "columar-staggered": {"description":"Keys laid out with the columns offset from each other"},
    }
}

Some suggestions:

• tag_categories/layout should have "jis" too, I know there's a board or two that support JIS layout.
• tag_categories/percentage and tag_categories/formfactor overlap a bit, and maybe should be combined.
• tag_descriptions should each list example keyboards, like:

    "tag_descriptions": {
        "ortholinear": {"description":"Keys laid out in a uniform grid with no stagger (Planck, BFO-9000, etc.)"},
        "row-staggered": {"description":"Keys laid out with the rows offset from each other (standard QWERTY)"},
        "columar-staggered": {"description":"Keys laid out with the columns offset from each other (Ergodox EZ, Atreus, etc.)"},
    }

Also, #1584

What if the split tag is instead a boolean key (default to false)?
Something like this:

{
    "keyboard_name": "ErgoDox EZ",
    "url": "ergodox-ez.com",
    "maintainer": "erez",
    "width": 19.5,
    "height": 9.375,

    "split": true,
}

Some keyboard has incorrect width and height values. I was thinking to write some code to check the correctness of these values but I have to exclude split keyboards. This option can also be useful for the QMK Configurator.

@i5ar

Some keyboard has incorrect width and height values.

Can you link an example or two? That may have been my doing. I set up the info.json files for quite a few split boards last year, and my custom was to separate the halves by 1u, and to separate the thumb keys from the main "key wells." The idea for both of those decisions was to make the keys easier to identify at a glance in QMK Configurator.

@noroadsleft Considering I haven't updated my QMK Firmware directory in a while, this is what I can tell at first glance.

Wrong width:

• 40percentclub/foobar;
• baguette (correct in the API);
• handwired/prime_exl;
• handwired/not_so_minidox;
• kbd4x;

Wrong height:

• canoe;
• clueboard/card;
• crkbd;
• crkbd/rev1;
• ergoinu (correct in the API);
• gergo;
• handwired/dactyl_manuform/5x7 (correct in the API);
• handwired/frenchdev (incorrect in the API);
• handwired/ortho5x13;
• handwired/promethium (tolerable);
• handwired/tradestation (incorrect in the API);
• speedo;
• xd87 (tolerable);
• zinc (correct in the API);

Wrong and width and height:

• ergodone;
• ergodox_ez;
• ergodox_infinity;
• keebio/iris (incorrect in the API);
• keebio/iris/rev1 (incorrect in the API);
• keebio/iris/rev1_led (incorrect in the API);
• keebio/iris/rev2 (incorrect in the API);
• keebio/iris/rev3 (incorrect in the API);
• orthodox/rev1;
• orthodox/rev3;
• orthodox/rev3_teensy;
• qwertydox;

When I say incorrect in the API that means that is probably incorrect in info.json as well.
When I say correct in the API that means that is (or was) incorrect in info.json.

Regarding keyboards like the ergodone, the ergodox_ez and the ergodox_infinity the width may be already correct if you want the split parts to be more distant (like in KLE) but then all the keys of the right split must move.

I may review and check this list when I have more time.

K, I've checked about half of your list and here's where I'm at:

Bugged (Incorrect data in info.json)

• 40percentclub/foobar
• handwired/prime_exl
• kbd4x
• handwired/not_so_minidox
• canoe
• clueboard/card
• crkbd + crkbd/rev1 (keyboards/crkbd/info.json)
• gergo
• handwired/dactyl_manuform/5x7
• handwired/frenchdev
• handwired/ortho5x13
• handwired/promethium

Accurate near as I can tell

• baguette
• ergoinu

@noroadsleft I can confirm that baguette and ergoinu have been fixed and they are accurate now.

Plus handwired/dactyl_manuform/5x6, handwired/dactyl_manuform/5x7 and handwired/dactyl_manuform/6x6 seem to have some other issue in the API (you can see from the configurator) but in the info.json the only problem is the height (only handwired/dactyl_manuform/5x7).

What's the issue, specifically? The Dactyl Manuform variants you've listed all look how I intended them to look.

@noroadsleft a few hours ago they looked messed up in the configurator. They look good now (I don't know what happened).

I forgot to consider the timeline. They were broken when you posted that they were, but my pull request linked above was merged before I asked you for the specific issue. I made a pull request specifically to fix the issue (which persists for other boards).

I've done a lot of these so I know how the integration works.

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.
For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

info.json has support for the tags object, with an array of strings.