This is a first step to decouple formatting from information because of
two reasons:
1. The components should only gather and return the values by design
2. Fine grained user control should be a focus
Scaling will be implemented in a different way in a later commit.
On some laptops (mostly thinkpads), the remaining time may be
expressed in µWh using energy_now and power_now files rather than µAh
for charge_now and current_now.
Add pick function to conditionally select appropriate one.
These functions take the raw number and a unit and automatically
print it out "scaled down" to a proper SI-prefix, for powers of 2
and 10 respectively.
Apply them to the 2-power cases and keep the 10-power for a later
commit.
First dividing by interval before multiplying with 1000 decreases the
precision by +-(interval - 1) * 1000, as interval arithmetic always
applies the Gauß-function to the result.
This is not necessary and simply reordering the operations mitigates
this.
Within the components, snprintf() was unchecked and had inefficient
calls in some places.
We implement esnprintf() that does all the dirty laundry for us
and use it exclusively now.
implemented the netspeed functionality for openbsd.
furthermore the static keyword was removed of the interval variable in
config.def.h for usage as extern variable.
when an AC is connected apm_info shows a non-valid value for remaining
minutes. it was decided that in that case the function should return an
empty string.
Implementation of a battery_remaining function which returns the
remaining battery time in HH:MM format. Linux function still needs
implementation.
Move common code to load_apm_power_info
Given slstatus is a tool that runs in the background, most likely run
from .xinitrc, it's important to prepend the name of the tool to error
messages so it becomes clear where the error is coming from.
To make this much more consistent, this commit adds warn() and die()
utility functions consistent with other suckless projects and adapts all
calls to fprintf(stderr, *) to the warn() and die() functions, greatly
increasing the readability of the code.
The swapctl(2) function fills the swapent struct with 512KB blocks.
As we want to display in GB, i just modified the calculation for this to
get the expected output.
- Use block for single statement ifs
- Keep lines to reasonable length (current debate as to reasonable)
- When functions return -1 for error test against 0 not -1
- Do not indent cases another level
- Do not test against NULL and 0 explicitly
- Use tabs for indentation, use spaces for alignment
The third value from load_avg (idle) gives us almost the same
information as cpu_iowait. Plus OpenBSD does not offer an iowait value
as Linux and thus the corresponding function would not be portable.
Granted, this style is definitely not common, but for the short
utility-functions of this program it's just the right choice. This
provides great flexibility, such that in the long run, it will be
possible to also share code between the OS-implementations.
This also keeps the state-keeping at a minimum and makes it clearer
which functions are implemented on which OS without having to jiggle
around with too many files in the process.
this reverts the commits from 92ab9ef52e up to
d42870d6ca.
After heavy consideration, the component split has more disadvantages
than advantages, especially given there will be utility-functions
sharing quite a lot of code that would then need to be duplicated, as it
does not fit into the util.c due to its speciality.
One big advantage of the component-wise build is readability, and
without doubt, this was achieved here. This point will be addressed
with a different approach that will be visible in the upcoming commits.
One big disadvantage of the component build is the fact that it
introduces state to the build process which is not necessary. Before its
introduction, the only influencing factors where the system-defines
__linux__ and __OpenBSD__. With the components, we are also relying on
the output of uname(1).
Additionally, if the os.mk is not present, make gives the output
$ make
Makefile:5: os.mk: No such file or directory
make: *** No rule to make target 'os.mk'. Stop.
This could easily be fixed by providing some sort of meta-rule for this
file, however, it indicates the problem we have here, and this entire
statefulness will heavily complicate packaging of this tool and makes
the build process much more complex than it actually has to be.
Aaron Marcher
David Demelier
Tobias Tschinkowitz
Laslo Hunhold
Josuah Demangeon
parazyd
Quentin Rameau