Going modular

[urob]

Currently, this config relies on a custom ZMK fork for the building. Historically, that fork included many experimental features, many of which are now part of upstream ZMK or are available as ZMK modules.

My hope is that with the module ecosystem growing, I'll be eventually able to build against upstream ZMK and a few modules. In c8b4369, I started making this transition. Instead of using my main ZMK branch to build my firmware, I'm now using going-modular.

Update: The modular setup is now merged into the main branch of my ZMK repo. The old main has been renamed to main-3.5. Neither main-3.5 nor going-modular will be maintained going forward.

The following tracks the remaining patches merged in main.

• require-prior-idle (merged upstream)
• combo + hold-tap fixes (merged upstream)
• masked-mods fix (merged upstream)
• hold-on-release for balanced (merged upstream)
• rolling repeat fix (merged upstream)
• Pointer core/mouse keys (merged upstream)
• Pointer/movement scrolling PR (replaced by new mouse PR)
• New pointer/movement scrolling PR
• tri-state behavior PR (replaced by tri-state module)
• smart-word behavior PR (replaced by auto-layer module)
• hold-on-release for tap-preferred (no replacement needed ¹)
• Zen display & battery tweaks
• Leader key PR (replaced by leader-key module)
• Generic desktop usage page

In addition, there are two new module-related patches:

• Fix test.py (merged upstream)
• Workaround for an upstream west issue (#725)

One of the remaining features (mouse movements) is huge and it finally being merged upstream is widely anticipated.

Once it is, the biggest reason for me to keep using a custom ZMK fork are @caksoylar's tweaks for my Corneish Zen.² For other boards, I am expecting to be able to build against an almost vanilla upstream ZMK.

Footnotes

1. I kept this commit around as a courtesy for people who wanted to play around with hold-tap flavors and still use positional hold-taps. But since I am only using the balanced flavor myself, there's no need to keep it in my ZMK branch. ↩

2. Those tweaks rely on some core changes that can't be easily moved to a module. ↩

[dhruvinsh]

Glad to see that tri-state module proof of concept working out great. :)

Awesome work. 👍🏼

[urob]

Yes, thanks for figuring out how all the modularization stuff! I also used it as a reference for modularizing the updated auto-layers behavior. Really very useful!

[urob]

Btw, not sure if you want to keep around the old num-word implementation. But maybe it's worth adding a comment about how it is different from the new auto-layers so people don't get confused?

[dhruvinsh]

Btw, not sure if you want to keep around the old num-word implementation

definitely I don't plan to develop it, it was just your work with proving that modularization can be done. I will have note on the repo pointing to your valid work, In-fact I was just waiting for that :)

I will keep the swapper aka zmk-tri-state as it is as Nick haven't posted any changes yet, let see, 🤞

[infused-kim]

Amazing work. Thank you for sharing it all!

[minusfive]

Thanks @urob! Updated my config, no issues, working flawlessly.