Features

WYSIWYG keymap editing

Existing .keymap files are parsed and laid out in a visual editor (see Wiki: Defining keyboard layouts). The generated list of keybinds are then formatted to match the layout of the keyboard in order to maintain readability.

The original keymap code is a first class citizen, so any time you need to you can go ahead and edit your source directly without breaking compatibility.

Combo editing

This allows you to assign a key bind and select input keys visually using a scaled down mapping of the keymap layout. Supports further configuration of the timeout, slow-release, and layers properties.

The same behaviours and key codes are available here so your combo can even trigger custom behaviours or macros you defined within the app!

Macro editing

This feature enables editing macros defined in your .keymap file (as well as creating new ones of course) and assigning them as custom behaviours in your keymap. Eventually this will support reading macros that you may have your keymap include from separate .dtsi files.

Parameterized Macros (tentatively ready)

ZMK Added support for Parameterized Macros some time ago and I had a few roadblocks to work out in order to add support for the functionality in the editor. For a little detail on that see Wiki: Limitations of the Keymap Editor - Parameterized Macros.

Update: this is a little fresh off the presses but parameterized macros should be pretty much ready now:

• Existing parameterized macros should be parsed out of your keymap
• New parameterized macros will inject placeholders automatically in bindings that are preceded by a &macro_paramXtoY-type binding.
  • When adding/removing these bindings the macro's compatible and #binding-cells properties will be automatically adjusted as needed
• Macro parameter substitutions are used to determine the expected parameter types when binding the macro to a key/combo/etc, with the exception of trying to parameterize the first argument to &bl, &bt, and &rgb_ug* behaviors
• The macro editor will attempt to detect a few ways that macro parameters are being used incorrectly or in a way that may not work as intended, and will display these warnings. Hovering over the icon next to such a warning message will highlight the relevant binding(s) in the list.

^{*If you've read my blurb about limitations I hope you can appreciate that this is quite hard. For many behavior types parameter resolution is fairly trivial but with those that accept a "command" parameter that optionally requires an additional parameter to be added there's an undefined behavior for trying to target the first parameter. In this case and any other where I just can't figure it out the result will be treating it as a "raw" parameter where you enter whatever you want without assistance from the app. Truthfully I can't think of a use case for why you'd want to use parameterized macros this way but please drop me a line if you feel I've missed something.}

Behavior editing

Custom behaviors in your keymap (like homerow mods!) can be bound to keys in the keymap (and combos, and macros!). Through the app you can create custom behaviors based on the schemas available in ZMK main, and override configurations of the base behavior definitions.

Keymaps using behaviors only available in feature branches (like the mouse PR) is possible, but for the time being you won't be able to use the app to:

• create new versions of those behaviors
• reference the behaviors in any bindings

A sort of workaround for now is to create (directly in the keymap code) these behaviors referencing the correct zmk,behavior-... value. Because the schema isn't known to the keymap editor you still won't be able to edit the behaviors in the app or resolve its parameters correctly, but you'll still be able to reference them in other bindings.