4 ms·
I ended up using AHK for komorebi[1] because I was still new to Windows when I started writing it and I didn't wanna have to write a tiling window manager AND a
by bsnnkv 4y ago
I ended up using AHK for komorebi[1] because I was still new to Windows when I started writing it and I didn't wanna have to write a tiling window manager AND a hotkey daemon. I even ended up generating a nice little AHK library to wrap around CLI commands that sent socket messages to the window manager to make it easier to write a configuration.
Ultimately the syntax changes make it impossible to fully reproduce the same library for AHKv2, which is being installed by default on all mainstream package managers now.
I ended up biting the bullet and making my own hotkey daemon[2] for use with komorebi based on skhd[3] and I haven't looked back since. This will be the "blessed" hotkey daemon recommended for use in the next release of komorebi.
I'm still using AHK (v1) for the stuff that it's good at (and there is a lot of stuff that it's good at!), but ultimately I've found that it's not the right tool as a hotkey daemon for a socket-based tiling window manager (or just generally, for triggering CLI commands).
[1]: https://github.com/LGUG2Z/komorebi https://github.com/LGUG2Z/komorebi
[2]: https://github.com/LGUG2Z/whkd https://github.com/LGUG2Z/whkd
[3]: https://github.com/koekeishiya/skhd https://github.com/koekeishiya/skhd
- maximus-decimus 4y agoCan't you just right click on you script and pick "compile" or something similar to pack the v1 interpreter with your code? I remember a functionality like that existing.
- bsnnkv 4y agoI don't think it's quite that simple with this use case[1][2], but I'm happy to be proven wrong! [1]: https://github.com/LGUG2Z/komorebi/blob/master/derive-ahk/src/lib.rs https://github.com/LGUG2Z/komorebi/blob/master/derive-ahk/sr... [2]: https://github.com/LGUG2Z/komorebi/blob/master/komorebic.lib.ahk https://github.com/LGUG2Z/komorebi/blob/master/komorebic.lib...
- pletnes 4y agoI just downloaded v2, purely by incident (haven’t used AHK for some time) but there is now official support for compile-to-exe. No idea how good it is, I’ve only used AHK for one-offs, short term projects, etc.
- mkl 4y agoThat's in v1 too.
- diarrhea 4y agoThanks for creating komorebi. I had tried to set it up a while ago but had to give up. Configuration was a bit arcane! I wonder if other TWM are like that as well. I just wanted to upgrade from PowerToy’s zone manager, but the step from that to komorebi was very steep. Maybe one day there’s a more idiot-proof approach to komorebi! ;)
- bsnnkv 4y agoI'll start working on a full setup video to post on YouTube once I have finished packaging and getting whkd onto the common package managers! Keep an eye out in the next month or so.
- dicytea 4y agoWished that you chose toml/yaml/json/etc. for the hotkey daemon. One thing I don't like about new custom DSLs is that they usually don't come with a syntax highlighter and auto-formatter. Also, will you also get rid of the *.generated.ahk stuff in the next release? It would be far more ergonomic if komorebi can just read and apply the yaml config directly.
- bsnnkv 4y agoI'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. [1]: https://github.com/baskerville/bspwm#description https://github.com/baskerville/bspwm#description