| Age | Commit message (Collapse) | Author |
|---|
|
use format_placeholder for ddate
|
|
|
|
|
|
|
|
related to #331
Previously, if max_chars was read, the null byte would be written
past the end of buf.
|
|
Added a function to print file contents to status bar without newlines.
Added tests for print file contents function
Added manpage entry for file contents
|
|
|
|
|
|
|
|
|
|
`print_battery_info` computes `batt_info.percentage_remaining` by
dividing batt_info.remaining by `full`. If `full` is `0` then the
battery remaining will be reported as "inf".
Before this, it tries to set `full` to either the design capacity or to
the last known good charge. It determines if these values are available
by checking whether their fields in `batt_info` are non-negative. As it
initialized `batt_info` with values of `-1`, a non-negative value
implies that something has provided a value.
`slurp_all_batteries` and `add_battery_info` however initialize these
fields to zero, so if these functions are called then
`batt_info.full_design` will always be used.
This means that on systems that don't provide a value for design
capacity the percentage remaining will be reported as "inf", unless the
user has set `last_full_capacity` to `true` in their `i3status.conf`.
This patch changes `print_battery_info` to expect values for the battery
capacity to be strictly greater than zero. This seems reasonable as a
battery with a capacity of zero isn't useful.
An alternative solution would be to change `slurp_all_batteries` and
`add_battery_info` to initialize `batt_info` with `-1`, as
`print_battery_info` does. This is less appealing as `add_battery_info`
is accumulating the values, so using `-1` would introduce off-by-one
errors without additional code to avoid them.
|
|
|
|
Support any amount of available cores on testing machine.
|
|
The Linux power supply class defines three entries to provide battery status.
One of them wasn't used: POWER_SUPPLY_CAPACITY.
https://www.kernel.org/doc/Documentation/power/power_supply_class.txt
|
|
This change addresses the issue #199 asking for multiple CPU support. It
takes an arbitrary CPU number and outputs its usage using the same
arithmetics as for CPU aggregation. It currently doesn't support
FreeBSD.
|
|
|
|
Provide format_above_threshold/format_below_threshold options
|
|
|
|
The valid test case assumes pid 1 exists, which should always
be true on Unix environment.
|
|
|
|
|
|
|
