greshake / i3status-rust

Very resourcefriendly and feature-rich replacement for i3status, written in pure Rust
GNU General Public License v3.0
2.85k stars 470 forks source link

It seems no warning_cpu/critical_cpu values can be set #1915

Closed c02y closed 7 months ago

c02y commented 1 year ago

https://github.com/greshake/i3status-rust/blob/e02ea1ed9cef85be53f43890e85f4eb602554804/src/blocks/cpu.rs#L133-L136

Values are hard coded 0.9/0.6/0.3?

MaxVerevkin commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.