(Design suggestion) Replace KDL with TOML on the configuration file

[hardBSDk]

The syntax is more easy.

[YaLTeR]

I don't agree that the TOML syntax is that much easier. On the contrary, I think that the lack of indentation makes the config more difficult to understand.

Either way, I wouldn't be necessarily opposed to switching from KDL to a more widely known format. However:

1. I like the current config structure for the most part, so the new format should be able to express the same structure, or with minor reasonable tweaks (which is for me to subjectively decide).
2. Adding new options should not involve any more code than it does now. In the current setup a derive macro does most of the heavy lifting, so for many options I only need to add the bare minimum derive annotations on top of the structures I'm adding.

[zkat]

side-note: we're working on a KDL 2.0 spec that would make these configs even nicer :) https://github.com/kdl-org/kdl/blob/29495006bc9eec4c508d60cd3b7de1d1f2773768/CHANGELOG.md

For example, you'd be able to do:

binds {
    Mod Ctrl Left  { move-column-left }
    Mod Ctrl Down  { move-window-down }
    Mod Ctrl Up    { move-window-up }
}

All that said, I think KDL is a great fit and it makes me happy to see it get used here! I think it looks great. I think I'm gonna have to switch from Hyprland after all :)

[YaLTeR]

Hey! Thanks for working on KDL, it is really quite pleasant to use! 😀 Honestly, most of my problems are with the Rust KDL crates (they could use more work) and not with KDL the language itself.

For the language itself, off the top of my mind I can think of two things that I bumped into:

1. Requirement for the ; termination in { something; }—I see that's no longer the case in 2.0.
2. Requirement for quoting argument strings as in spawn "alacritty" "-e" "fish"—I see that's also fixed in 2.0.

So yeah, that's great!

[zkat]

I've heard of some issues with knuffle, too, and I'm hoping to add built-in serde support to kdl-rs itself when I work on adding KDL 2.0 support, which I'm hoping will make the implementation situation a bit better :)

[workingjubilee]

Technically, TOML does allow indentation.

However, TOML does not recommend indentation, and for a reason possibly worse, at least for niri's config, than a format that is overly picky about that: TOML does not prioritize nesting. Consequently, it has no way to name a table except from the root, or as an "inline table" (a table-value, in effect), which is limited to one line. This lack of affordances means there's not really a ton of good mid-points between

[dependencies]
sample_crate = { version = "1.99.9-rc9", features = ["one", "two", "buckle-my-shoe"] }

And a later evolution like:

[dependencies.sample_crate]
version = "1.99.9-rc9"
default-features = false
registry = "ersatz-crates"
features = ["one", "two", "buckle-my-shoe"]

[target."cfg(all(target_env = "air", target_os = "jordans"))".dependencies.sample_crate]
features = [
    "three",
    "four",
    "buckle-some-more",
    "five",
    "six",
    "nike-kicks"
]

If a configuration file may face deeply nested structures then it needs a better way to manage this than TOML affords. This is especially true with conditional relations, since the natural conditional is key lookup, nesting for each condition. As mere nesting can cause strife for TOML, and the overall structure is likely to remain similar per Yalter's response, the default-config.kdl already has samples that would suggest something other than TOML:

niri/resources/default-config.kdl

Lines 4 to 7 in 738d9a2

	input {
	keyboard {
	xkb {
	// You can set rules, model, layout, variant and options.

Any serious recommendations of alternatives would have to compensate for this.

[kchibisov]

I'd add a note as a person who suggested to move away from kdl a bunch of times in the past. However the reasons were mostly technically since the KDL implementation in rust brings a lot of deps(compared to TOML) and and unless the config was moved to its own crate with debug being literally always disabled (because otherwise niri binary is now ~1GB) and we also test that it's not get enabled back again.

It was also adding to the fact that smithay itself tends to generate a lot of debug artifacts (though it doesn't really increase the binary that much), but it just increases target quite a lot, thus after a few days on hacking niri you tend to discover that your target is around ~50-70GB (it was like that for me for example, while on my separate branch with just TOML I had it way-way less ~5GB).

If a configuration file may face deeply nested structures then it needs a better way to manage this than TOML affords. This is especially true with conditional relations, since the natural conditional is key lookup, nesting for each condition. As mere nesting can cause strife for TOML, and the overall structure is likely to remain similar per #73 (comment), the default-config.kdl already has samples that would suggest something other than TOML:

That's way nicer in TOML though, since it'll be just

[input.keyboard.xkb]
layout = "us,ru"

And you can write it like

[input.keyboard."my-keyboard".xkb]
layout = "us,ru"

if you want more fancy per-keyboard configs.

Zero indention as well and just 2 lines, so it's not a real argument.

The place where KDL really looks good is when arrays are involved, ihmo, that's why I suggested to use scfg instead, which is really simple as well and is what sway/i3 and a bunch of other libraries use, and it's simple to parse as well. But with scfg there're no good libs around it, nor people interested in making them in rust for the time being. There're a few really simple, but that's mostly it.

So I'd say that TOML config is more compact in general, but it's a bit tricky to do bindings and global sections with it and in compositor the majority of what you have is actually bindings, rust toml libs are also not that great with error propagation (passing line/column is a pain), because serde devs just don't care about any of that and you can basically pass that only via globals or by using special containers, but those containers are basically the Value in toml crate and it's just not a good thing if you ever have imports, because then you'd have to carry stuff via globals(like if you want to report unused fields, etc).

[YaLTeR]

FWIW, before release, as an experiment, I did a mostly-complete conversion to TOML to see how it would look like. You can see an example here:

niri/src/config.rs

Line 576 in a4adf56

[input]

and also here: https://gist.github.com/YaLTeR/e772071917161d2dfa6f488eb17b74cb. Those are both incomplete, as in I would make some more tweaks to the TOML config structure if I were to go through with it.

Later I remembered that you can disable debuginfo for specific dependencies, which solved my by far main issue with knuffel (the KDL parser we're using).

[zkat]

I went ahead and rewrote my config.kdl in kdl v2, and I think it feels a lot better. TBH I agree that it was kind of a pain, especially when configuring spawned commands.

https://gist.github.com/zkat/beefc09ad8191dc7077290feceb19582

I also went ahead and played with changing how binding specification works, so instead of funny node names, you can just use arguments now:

    Mod Q { close-window }

    Mod Left  { focus-column-left }
    Mod Down  { focus-window-down }
    Mod Up    { focus-window-up }
    Mod Right { focus-column-right }
    Mod H     { focus-column-left }
    Mod J     { focus-window-down }
    Mod K     { focus-window-up }
    Mod L     { focus-column-right }

    Mod Ctrl Left  { move-column-left }
    Mod Ctrl Down  { move-window-down }
    Mod Ctrl Up    { move-window-up }
    Mod Ctrl Right { move-column-right }
    Mod Ctrl H     { move-column-left }
    Mod Ctrl J     { move-window-down }
    Mod Ctrl K     { move-window-up }
    Mod Ctrl L     { move-column-right }

I'll probably start updating kdl-rs soon and also see if I can add serde support in the process, but it might take me a bit :)

[YaLTeR]

That's very exciting! Although for binds specifically I do like the +, I'd say that's also the more usual way of writing them. (Besides, this allows it to be a HashMap<Key, _> so that duplicate keys are rejected at parsing rather than silently ignored.)

TBH I agree that it was kind of a pain, especially when configuring spawned commands.

Hah, yeah, I see you have a ton of those.

[kchibisov]

I'd suggest against serde for configuration, since literally no way to reliably propagate errors/warnings and once you ask devs they tell you that you do it wrongly. So every crate (e.g. toml) which tries to communicate errors ends up a bit complicated.

even if you look at toml, they have a value which carries the location, but the location is the offset into the input, but you don't have file along the way, etc, thus you have to somehow figure out stuff, but if you have more than one warning you need to somehow tag them and pass via global state, which already sounds like a lot of fun and joy in your life to handle, so you give up and report that something called X is wrong and that's about it.

[zkat]

The way the current kdl-rs parser is designed is more like toml-edit: navigating it is a bit more verbose than using serde, but it collects a lot of context information and has really great errors, as well as letting you do things like querying, formatting, programmatically editing and writing back out, etc.

I plan on having both, because sometimes people really just want the convenience of serde and call it a day.

[YaLTeR]

From my TOML experiment, serde does have some extra conveniences over knuffel, like struct-level #[serde(default)], but nothing ground-breaking. Also if you're wondering, I disabled the miette fancy feature because it brings in a whole tree of dependencies, which isn't really worth for just logging an error.

[nebulosa2007]

TBH I agree that it was kind of a pain, especially when configuring spawned commands.

That's true.
One day I wanted to configure my MediaKeys for to do somethings AND to show notification for the action. I just gave up in a third line and made this:

...
XF86AudioMute { spawn "bash" "-c" "$HOME/.config/niri/MediaKeys.sh XF86AudioMute"; }
XF86AudioRaiseVolume { spawn "bash" "-c" "$HOME/.config/niri/MediaKeys.sh XF86AudioRaiseVolume"; }
XF86AudioLowerVolume { spawn "bash" "-c" "$HOME/.config/niri/MediaKeys.sh XF86AudioLowerVolume"; }
XF86MonBrightnessDown { spawn "bash" "-c" "$HOME/.config/niri/MediaKeys.sh XF86MonBrightnessDown"; }
XF86MonBrightnessUp { spawn "bash" "-c" "$HOME/.config/niri/MediaKeys.sh XF86MonBrightnessUp"; }
...

and MediaKeys.sh is:

...
case $1 in
  XF86AudioMute         ) pactl set-sink-mute @DEFAULT_SINK@ toggle ; notify-send -c "system" " $(pactl get-sink-mute @DEFAULT_SINK@)"    ;;
  XF86AudioLowerVolume  ) pactl set-sink-volume @DEFAULT_SINK@ -5%  ; notify-send -c "system" " $(pactl get-sink-volume @DEFAULT_SINK@ | head -1 | tr -s ' ' | cut -d ' ' -f1,5)" ;;
  XF86AudioRaiseVolume  ) pactl set-sink-volume @DEFAULT_SINK@ +5%  ; notify-send -c "system" " $(pactl get-sink-volume @DEFAULT_SINK@ | head -1 | tr -s ' ' | cut -d ' ' -f1,5)" ;;
  XF86MonBrightnessDown ) brightnessctl -c backlight set 1- ; notify-send -c "system" " Brightness: $(brightnessctl -m | cut -d',' -f4)" ;;
  XF86MonBrightnessUp   ) brightnessctl -c backlight set +1 ; notify-send -c "system" " Brightness: $(brightnessctl -m | cut -d',' -f4)" ;;
esac
...