Is there any chance to support other keyboard firmware?

[hitsmaxft]

While searching for a keymap editing solution for RMK (rmk.rs), the idea came to me that it might be possible to build on a popular and well-designed keymap editor project.
Since I'm using ZMK at the same time, I focused on keymap-editor and did some research on it.
I found that keymap-editor uses QMK JSON and ZMK DTS for rendering layouts, and saves keymaps into DTS files for ZMK.
’m wondering whether the current architecture of keymap-editor is designed in a way that allows support for multiple keycode systems.
Specifically, can the system be extended to handle different keycode formats beyond QMK and ZMK, such as custom or vendor-specific keycodes?

In addition to keycode compatibility, I’m also interested in whether the system supports reading keymap configurations from various formats — for example, RMK, ZMK, and QMK — and whether it can write back the changes to the original format after editing through the keymap editor module.

If the module structure is well-isolated and loosely coupled, it might be possible to introduce additional keycode systems and configuration storage formats with minimal effort.
I’d like to understand how flexible the architecture is in this regard, and whether adding support for new formats would require major changes or just minimal adaptation.

[nickcoutsos]

The short answer is no, unfortunately.

I started typing out a longer explanation but... oof. I guess one main point is that when I was supporting QMK and ZMK together it was by reducing both firmwares to such a generic tree of pickable values that you couldn't really do anything besides the most simplistic keymaps. Features like combos and macros take more work (from what I remember, QMK's combos function very differently from ZMK's using combining keycode instead of key positions) and ZMK's behavior composition is its own beast altogether.

I think if someone were to try to support multiple firmwares in depth they'd have to come up with a really detailed abstraction.