[st0le]

Used to use FZ but it relies on the user to move windows around. More of a passive window manager.

I've been using komorebi[1] but it's rather clunky with the ahk dependency. I'll have to try Glaze and give it a spin.

[1]: https://github.com/LGUG2Z/komorebi

[toothbrush6]

Yeah exactly, FancyZones feels like a bit of an upgrade over the built-in tiling (eg. with Win+Left/Right). It doesn't quite compare to keyboard-driven TWMs like i3 and bspwm.

[bsnnkv]

komorebi dev here. I can't tell you the number of times I've wanted to just write my own take on sxhkd[1] for Windows and use that to manage my own keybindings for komorebi instead of ahk.

You can just as easily write your own/use another hotkey daemon or PowerShell scripts to handle komorebi's configuration and keybindings, in that sense there is no dependency on ahk at all. However, the inertia around ahk in the Windows ecosystem is undeniable and it's in the interests of making adoption and onboarding easier that the project provides example ahk files and has invested in an ahk code generation library.

My thoughts on the dominant hotkey daemon in the Windows ecosystem aside, I remain convinced that the famous bspwm socket communication architecture[2] is the best way to handle both configuration and keybindings for a tiling window manager that has been proposed to this day.

Unfortunately I have to concede that there is a certain configuration burden that comes with komorebi, which is amplified in some cases by having to write/maintain ahk. This configuration burden is largely due to the highly fragmented nature of Windows application development that is discussed often on HN and it is inescapable.

With this in mind, the next release of komorebi (currently available on master) will invest even more heavily in automatic configuration generation.

A separate repository of common application-specific configuration tweaks[3] (in YAML!) has been created which I and others from the komorebi Discord server are contributing to, with the goal of having the edge cases for as many applications as possible fully documented so that a comprehensive configuration file can be generated[4] for the user which ensures that every (major) Windows application behaves as expected under a tiling window manager.

I hope that other Windows tiling window manager developers can use these YAML definitions in the future to handle the same edge cases in their projects so that eventually there will be a tiling window manager of every flavour (bspwm, i3wm etc.) available for Windows users where having to manually accommodate and compensate for the non-standard behaviour of individual applications is a thing of the past.

[1]: https://github.com/baskerville/sxhkd

[2]: https://github.com/baskerville/bspwm#description

[3]: https://github.com/LGUG2Z/komorebi-application-specific-conf...

[4]: https://github.com/LGUG2Z/komorebi/#generating-common-applic...

[st0le]

Thank you for your work. I definitely think it's much better than most solutions out there. I was exploring trying to get it to work with espanso[1] (also written in Rust) but haven't had much time.

[1]: https://espanso.org/

[emptysongglass]

From [4] in the command given to generate the common application configurations `komorebic.exe ahk-app-specific-configuration applications.yaml`, the argument `ahk-app-specific-configuration` doesn't exist in the latest release version, v0.1.8.

[bsnnkv]

v0.1.9 coming soon (TM)! This[1] is the readme for v0.1.8.

If you want to try out the new features coming in v0.1.9 (including this one), you can follow the build steps from the readme on the master branch or download a zip containing the compiled binaries of the latest development build[2] by clicking on the green "tick" icon next to the latest commit and downloading the "komorebi-x86_64-pc-windows-msvc" artifact.

[1]: https://github.com/LGUG2Z/komorebi/tree/v0.1.8

[2]: https://github.com/LGUG2Z/komorebi/actions/runs/2192874049