I'm sorry you got downvoted for this comment, for what it's worth I tried voting it back up.
The DSL is largely "borrowed" (stolen) from skhd, which has been around for a long time, so most existing shkd-syntax-compatible tools should(*) work, but I think I will take the time to also write tools specifically for whkd in the future based on this comment.
TOML/YAML/JSON are imo even worse than AHK for configuring hotkeys that trigger potentially complex CLI commands. There always comes a point where the user is stuffing an entire sh script into a string and suffering in escape sequence hell.
You can take a look at the feature/whkd branch on the komorebi repo for an idea of how this will look going forward.
Backwards-compatibility with all the AHKv1 generated libraries will remain for users who don't want to move to AHKv2 or whkd, and a new PowerShell generation target will complement the AHKv1 generation targets, finally bringing komorebi full-circle back to the bspwmrc/yabairc model of configuration using a script in the configured system shell (which also launches the hotkey daemon).
As for moving away from the "bspwm architecture"[1] (I think this is what you meant by "read and apply the yaml config directly?) - this will never happen. I've written before about how I feel that the bspwm architecture is the endgame for tiling window managers, and my thoughts on this topic haven't changed.
The komorebi license is pretty permissive so anyone is free to fork it and change it if they dislike the bspwm architecture that much.
The DSL is largely "borrowed" (stolen) from skhd, which has been around for a long time, so most existing shkd-syntax-compatible tools should(*) work, but I think I will take the time to also write tools specifically for whkd in the future based on this comment.
TOML/YAML/JSON are imo even worse than AHK for configuring hotkeys that trigger potentially complex CLI commands. There always comes a point where the user is stuffing an entire sh script into a string and suffering in escape sequence hell.
You can take a look at the feature/whkd branch on the komorebi repo for an idea of how this will look going forward.
Backwards-compatibility with all the AHKv1 generated libraries will remain for users who don't want to move to AHKv2 or whkd, and a new PowerShell generation target will complement the AHKv1 generation targets, finally bringing komorebi full-circle back to the bspwmrc/yabairc model of configuration using a script in the configured system shell (which also launches the hotkey daemon).
As for moving away from the "bspwm architecture"[1] (I think this is what you meant by "read and apply the yaml config directly?) - this will never happen. I've written before about how I feel that the bspwm architecture is the endgame for tiling window managers, and my thoughts on this topic haven't changed.
The komorebi license is pretty permissive so anyone is free to fork it and change it if they dislike the bspwm architecture that much.
[1]: https://github.com/baskerville/bspwm#description