Feat: TOML config w/ conditionals + backwards compatibility

[SDG-Den]

I've updated all config keys to a new dot-separated segment-based standard, old config keys are kept parseable as "global" keys.

new functionality:

• [header.name] TOML like headers which get prepended to every key in the block
• [ ? exit 0] conditional blocks based on the exit code of any command
• rules, binds, env, exec and source are all global (works from anywhere)
• made config .toml by default, will fall back on .conf if a .toml is not available (fully backwards compatible)

part of example config:

[deco.animation]
enable = 1
type.open = slide
type.close = slide
fade.in.enable = 1
fade.out.enable = 1
tag.direction = 1
zoom.initial.ratio = 0.4
zoom.end.ratio = 0.8
fade.in.begin.opacity = 0.5
fade.out.begin.opacity = 0.8

[deco.animation.duration]
move = 500
open = 400
tag = 350
close = 800
focus = 0

[deco.animation.curve]
open = 0.46,1.0,0.29,1
move = 0.46,1.0,0.29,1
tag = 0.46,1.0,0.29,1
close = 0.08,0.92,0,1
focus = 0.46,1.0,0.29,1
fade_out = 0.5,0.5,0.5,0.5
fade_in = 0.46,1.0,0.29,1

# Appearance
[deco.color]
root = 0x201b14ff
border = 0x444444ff
drop = 0x8FBA7C55
split = 0xEB441EFF
focus = 0xc9b890ff
maximize = 0x89aa61ff
urgent = 0xad401fff
scratchpad = 0x516c93ff
global = 0xb153a7ff
overlay = 0x14a57cff

# Scroller Layout Setting
[layout.scroller]
structs = 20
default.proportion = 0.8
default.proportion.single = 1.0
focus.center = 0
prefer.center = 0
edge.pointer.focus = 1
edge.focus.allow.speed = 0.0
proportion.preset = 0.5,0.8,1.0

# Master-Stack Layout Setting
[layout.master]
new.is.master = 1
default.mfact = 0.55
default.nmaster = 1

# Dwindle Layout Setting
[layout.dwindle]
smart.split = 0
drop.simple.split = 1
manual.split = 0
hsplit = 1
vsplit = 1
preserve.split = 0

for now, this is just done through some minor edits to the existing parser. In the future, it might be better to move to a premade TOML parser if the full TOML featureset is needed.

[DreamMaoMao]

I tend to view the issue from the perspective of an ordinary user (not a developer). The current configuration is still the least difficult for non-developers to understand. Of course, I might be wrong, so I still pay attention to the number of likes on the issue. However, so far, it seems that not many people like this toml format, except for a few developers

[SDG-Den]

understood, will keep the PR around for a bit to see if it is popular, main reason for picking this format is because the current mainline mango config is already very close and it can be supported without ruining backwards compatibility.

if it's better to keep the keys as underscore-split instead of dot-split (in-line with current and making the new parsing 100% optional), let me know.

[xdavidel]

I tend to view the issue from the perspective of an ordinary user (not a developer). The current configuration is still the least difficult for non-developers to understand. Of course, I might be wrong, so I still pay attention to the number of likes on the issue. However, so far, it seems that not many people like this toml format, except for a few developers

From your point of view I take it you wont like the idea of converting the configuration into scripting language like Lua for example, right?

I think simplicity is great, but it comes at the cost of flexibilty (which TOML will not solve anyway)
Using a real scripting language will add dynamic / conditional settings to be applied and also might allow implementing an event system in which the user can do various actions (for example when connecting a new monitor)

[SDG-Den]

I tend to view the issue from the perspective of an ordinary user (not a developer). The current configuration is still the least difficult for non-developers to understand. Of course, I might be wrong, so I still pay attention to the number of likes on the issue. However, so far, it seems that not many people like this toml format, except for a few developers

From your point of view I take it you wont like the idea of converting the configuration into scripting language like Lua for example, right?

I think simplicity is great, but it comes at the cost of flexibilty (which TOML will not solve anyway) Using a real scripting language will add dynamic / conditional settings to be applied and also might allow implementing an event system in which the user can do various actions (for example when connecting a new monitor)

i've actually been thinking about how to approach this, because i do not think a scriptable config is a good idea for the average user, but i would like to provide it for power-users.

currently, it's actually somewhat doable to configure mango entirely in bash/zsh/fish through mmsg! i actually have a working demo on my PC for this. this is done through the setoption dispatcher.

I'm considering that it may be possible to add full "scriptable config" support without overhauling the config interpretation (which is currently a hand-rolled simple config parser, that i managed to extend with ~100 lines of logic to support most toml features).

this would be done through making libraries for interacting with the mango socket via various languages (including LUA), I believe this has a pretty decent potential for working but we would need to introduce some more IPC functionality (like for example the dispatchers for border colors, borderpx and border radius i introduced in my border textures PR)

basically: if we can expose more things to the IPC and allow control via the socket, we could easily make mango able to be configured in its current format, TOML and any scripting language of your choice, with language support not being maintained by the main mango project, but rather by whoever wishes to write the library implementation for it.

edit: actually did some more digging and compared the concept implementation i did in bash with what you can do with hyprland, to make mango fully configurable in scripting through the ipc, the actual in-source changes that need to happen are:

• config readback (mmsg get option)
• the ipc needs to return real errors, not just success or failure, especially on setoption
• there's some small issues with certain actions relating to setoption re-setting env or re-triggering exec.
• current option args split on comma are a bit fragile as syntax in various other langs, but that can be handled by the lib instead of mango
• there's no way to currently unbind a key through IPC

these all seem to be relatively doable tweaks to mango, and once they're in, they could allow a scriptable config alongside existing config options, in any language through a library.

[Samq64]

I also don't think a full scripting language is the right fit for this project. I do like TOML though for its well defined syntax and the potential for a future schema with LSP integration while staying user-friendly compared to other options like JSON, YAML, or XML.

I am also happy keeping .conf though now that most of the configuration quirks have been ironed out.

[TrickyFatCat]

I tend to view the issue from the perspective of an ordinary user (not a developer). The current configuration is still the least difficult for non-developers to understand. Of course, I might be wrong, so I still pay attention to the number of likes on the issue. However, so far, it seems that not many people like this toml format, except for a few developers

I'm a bit more than average user, but not a software developer. The more I work with .toml files, the more I like them. They are easy to read, and they easily create a very neat structure by default. Current .conf files are fine for very small things, but long window rules are really hard to read, as everything just merged together. In general, WMs are for power users, thus you won't see a lot of average users using them unless it was preconfigured. .toml is definitely better than scripting languages, json, kdl approach if you want approachable config.

[dl09r]

If this PR was merged, could be have both worlds... the original config approach and this newer approach? That way, if someone (new user) wants to just get going without understanding the .toml formatting, they can get going with the default config.

Ultimately, satisfying both the user/beginner and an experience use who is looking for a little more flexibility and functionality. I would love to sponsor this PR.

Just my two cents...