How to programmatically change configuration parameters?

[Yaroslav-95]

Is there a way to programmatically change any configurable parameter of niri, such as with swaymsg? I tried looking through niri msg's help messages, but I didn't find a way to change, for example, gaps' size or the pointer acceleration.

Please correct me if I'm wrong, but it seems as though there's only a limited set of "actions" that can be performed with niri msg, as opposed to swaymsg which allows you to change on the go anything that can be set through the config file.

[YaLTeR]

You can apply transient output config changes with niri msg output, for other things you can just edit the config file on disk (for example, with sed). The changes will be picked up since it's live-reloaded.

[Yaroslav-95]

Well, I personally don't need to change each and any setting that niri offers in its config, but it would be nice if it was possible, so that you didn't have to make a sepparate command for each setting that anybody ends up needing to change in the future.

The way sway/i3 works, for example, is that all configuration settings are basically commands, and they are read from the configuration file upon config sourcing. But since all settings are commands, that means that all of them can be changed through IPC with the help of swaymsg or any other tool that speaks i3/sway's IPC protocol.

Maybe in the case of niri it could be something like

niri msg set layout gaps 10

[YaLTeR]

Right, in niri the config is explicitly not commands-based, but rather parsed into types. This allows for robust live-reloading, for example if you apply transient output config changes, then edit your config in some other part (don't touch the outputs), your transient output config won't be reloaded and undone. Can't really do that with a commands-based config.

The following just came to my mind about transient config changes. So there's plans to add some way to include in the niri config. At first, without intersections (so you can't have two layout {} sections with different settings) for ease of implementation, but later adding support for intersections (this will need changing the types quite a bit). Then, we could add some kind of niri msg load-config-part "layout { gaps 10; }" which will do the equivalent of transiently including those contents at the end of the current config.

This is only one command which works with any config change. Unfortunately, it's not an easy impl because it essentially requires the same type changes as support for multiple instances of a config section. Specifically: currently many config fields are just the type with a default value; instead there need to be "incomplete" versions of config structs where all fields are Option<Type> that can be merged together, and a resolution step that fills in the default values. (This is how window rules already work.)

[Yaroslav-95]

Oh, nice! include is one of the few other things that I'm missing from sway. Is there any open issue or discussion on include?

BTW, I have to say that I'm pretty impressed with niri. For such a new compositor project it is already quite usable as a daily driver, and I kinda don't want to go back to the more traditional tiling after using it for 3 days.

Thanks a lot!

[dragonnn]

Unfortunately, it's not an easy impl because it essentially requires the same type changes as support for multiple instances of a config section. Specifically: currently many config fields are just the type with a default value; instead there need to be "incomplete" versions of config structs where all fields are Option<Type> that can be merged together, and a resolution step that fills in the default values. (This is how window rules already work.)

I am wondering if using config crate https://crates.io/crates/config could do that without having to change anything in niri (I suspect only load a first "simplified config" to know what files to read)?

[YaLTeR]

Oh, nice! include is one of the few other things that I'm missing from sway. Is there any open issue or discussion on include?

I am forgetting; maybe, or maybe not.

BTW, I have to say that I'm pretty impressed with niri. For such a new compositor project it is already quite usable as a daily driver, and I kinda don't want to go back to the more traditional tiling after using it for 3 days.

Thanks :)

I am wondering if using config crate https://crates.io/crates/config could do that without having to change anything in niri (I suspect only load a first "simplified config" to know what files to read)?

Nah. The current system is based around derive traits from knuffel on top of static config structures, and a decent amount of custom parsing code.