Closed c02y closed 7 months 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.
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?
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.
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.
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.
https://github.com/greshake/i3status-rust/blob/e02ea1ed9cef85be53f43890e85f4eb602554804/src/blocks/cpu.rs#L133-L136
Values are hard coded 0.9/0.6/0.3?