It seems no warning_cpu/critical_cpu values can be set

[c02y]

i3status-rust/src/blocks/cpu.rs

Lines 133 to 136 in e02ea1e

	widget.state = match utilization_avg {
	x if x > 0.9 => State::Critical,
	x if x > 0.6 => State::Warning,
	x if x > 0.3 => State::Info,

Values are hard coded 0.9/0.6/0.3?

[MaxVerevkin]

PRs welcome :) By the way, it might be better to implement something like what the bluetooth block has instead of warning/good/info/etc.

[c02y]

https://docs.rs/i3status-rs/latest/i3status_rs/blocks/bluetooth/index.html#examples

[block.battery_state]
"0..20" = "critical"
"21..70" = "warning"
"71..100" = "good"

it seems this is new, but

https://docs.rs/i3status-rs/latest/i3status_rs/blocks/memory/index.html#example

warning_mem = 70
critical_mem = 90

So there are more than one standard of critical/warning for all blocks?

[ammgws]

Do you have a solution to go forward that doesn't break existing configurations? Maybe something like [block.memory_state] added to memory block which takes precedence over the existing warning_mem etc if set, then eventually the old way deprecated in a future release.

[c02y]

Do you have a solution to go forward that doesn't break existing configurations?

i3status-rust releases already broke its configuration for a few times, I almost get used to it.

Maybe something like critical/warming/info should be standardized like warning_fg/warning_bg for all the blocks that need this feature, for instance, warning format for disk_space.

[MaxVerevkin]

So there are more than one standard of critical/warning for all blocks?

Yeah, unfortunately. Bluetooth has it this way because it might be more intuitive (#1830) and it was sort of experimental.

Maybe something like [block.memory_state] added to memory block which takes precedence over the existing warning_mem etc if set, then eventually the old way deprecated in a future release.

This sounds good to me.