[jnordwick]

Been using hyprland on wayland for about a year now and the biggest issue is the constant config changes. It seems every version changes the config file, and you have to resolve the new errors and find the new knobs to turn.

That and I can't get my mouse cursor big enough or colorful enough -- and more of a wayland issue is that the pointer will change depending on window.

I don't really use it to its fullest extent though

[bsnnkv]

> the biggest issue is the constant config changes. It seems every version changes the config file, and you have to resolve the new errors and find the new knobs to turn.

I also maintain a very popular tiling window manager now (after years of suffering through breaking configuration changes with other twms) and this is the one thing that I will not budge on as a maintainer: Breaking configuration changes are unacceptable. Period.

From the contribution guidelines on the project README[1]:

> Breaking changes to user-facing interfaces are unacceptable

> ...

> No user should ever find that their configuration file has stopped working after upgrading to a new version of komorebi.

[1]: https://github.com/LGUG2Z/komorebi?tab=readme-ov-file#breaki...

[hollow-moe]

been also using komorebi on my windows for some time, I was really pleased to see how I could just update it with the rest of my apps through winget and it just works:tm:. Thanks for the amazing work. However don't you fear to get to a kind of CMake state with a "old" and "new" way to get things done being both available for the sake of backwards compatibility becoming quite a mess ?

[bsnnkv]

> However don't you fear to get to a kind of CMake state with a "old" and "new" way to get things done being both available for the sake of backwards compatibility becoming quite a mess ?

Right now there is support for dynamic configuration through commands executed through a script at startup (like bspwmrc etc), and declarative configuration through a static file which can be hot-reloaded.

Basically all new features and documentation are declarative-first, and there is a command that can generate a declarative configuration file from a running instance configured using a dynamic configuration script.

So if you're new to the project, you probably don't even know that the older configuration method is a thing, and if you come back to the project with a very old dynamic config script after a long time, everything you remember still just works, and you're just a command away from migrating to the format that everyone else is now using.

That being said, there is definitely a whole bunch of code that I would love to get rid of some day :)