Suggestion: consistent handling of format for good/bad/degraded
- Dominant language
- C
- Stars
- 653
- Forks
- 254
- PR merge metrics
- No merged PRs in 30d
Description
I've been fiddling trying to get the i3bar looking nice using i3status, but I keep ending up feeling annoyed with the inconsistency in how to configure it.
My suggestion to make it a much nicer (and more consistent) would be something like described below.
These 4 variables should exist for all "inputs":
format = "shared format that only changes color when threshold/triggers for bad/degraded is hit"
format_good = "when defined, override format for when a value isn't considered bad/degraded"
format_degraded = "when defined, override format for when a value is considered degraded"
format_bad = "when defined, override format for when a value is considered bad"
This would of course also imply that each type should allow the user to enter what good/degraded/bad values are as well.
While some things might seem weird (what is a bad or degraded date for example? 😄 ), staying consistent in how each type is configured would make it a lot easier to come up with how to configure them to one's desire without needing to read the docs for every step.
It also feels a tad backwards only being able to configure the default text-color inside the bar{ }-configuration of i3 rather than inside of i3status.
Especially as the only way to force a different color for "regular" output in the config for i3status is using pango-markdown, but doing so breaks the good/bad/degraded functionality.
Contributor guide
Assessment
This issue has not been assessed yet.