This consolidates all the time graph drawing to one main location, as well
as some small improvements. This is helpful in that I don't have to
reimplement the same thing across three locations if I have to make one
change that in theory should affect them all. In particular, the CPU
graph, memory graph, and network graph are all now using the same,
generic implementation for drawing, which we call (for now) a component.
Note this only affects drawing - it accepts some parameters affecting style
and labels, as well as data points, and draw similarly to how it used to
before. Widget-specific actions, or things affecting widget state,
should all be handled by the widget-specific code instead. For example,
our current implementation of x-axis autohide is still controlled by the
widget, not the component, even if some of the code is shared. Components
are, again, only responsible for drawing (at least for now). For that
matter, the graph component does not have mutable access to any form of
state outside of tui-rs' `Frame`. Note this *might* change in the
future, where we might give the component state.
Note that while functionally, the graph behaviour for now is basically
the same, a few changes were made internally other than the move to
components. The big change is that rather than using tui-rs' `Chart`
for the underlying drawing, we now use a tweaked custom `TimeChart`
tui-rs widget, which also handles all interpolation steps and some extra
customization. Personally, I don't like having to deviate from the
library's implementation, but this gives us more flexibility and allows
greater control. For example, this allows me to move away from the old
hacks required to do interpolation (where I had to mutate the existing
list to avoid having to reallocate an extra vector just to insert one
extra interpolated point). I can also finally allow customizable
legends (which will be added in the future).
Adds the asset for the manpage to cargo deb config. Also moves the generated manpage file to a .1.gz file. Also, moves back to a build script since that was causing some issues for the automatic Cargo.toml fields detection for manpage and completion generation.
To prevent compilation from happening every time, and only in CI, we use an env var to avoid generation steps.
Adds manpage generation to the build process, as well as following the xtask concept of adding additional build scripts that only need to run on deploy/nightly as opposed to `build.rs`. Note this doesn't follow the recommended method of using workplaces because I don't really want to shift the entire repo structure just for this.
More on xtask: https://github.com/matklad/cargo-xtask
Bumps up some dependencies and removes chrono, switching to the time crate instead.
One of side-effects of this change is that local time seems to not work (?)... so all logs are now in UTC. Oh well, this doesn't affect general user behaviour so I'm fine with it.
This is just a temp change, I wanted to remove it just for clarity's
sake among dependencies, and will probably add it back in the future.
For now I'll just stick to std's beef.
Refactor to split up data collection by OS and/or the backing library. The goal is to make it easier to work with and add new OS support, as opposed to how it was prior where we stored OS-independent implementations all in the same file.
Did not update crossterm (and tui-rs) since it seems to have resulted in a massive CPU usage increase. Also fix minor clippy error with a duplicated to_string call.
Fixes a bug where you could make the sorting arrow disappear in the mem column if you did:
1. Go to proc widget
2. Switch to memory values from %
3. Press `m`
Refactors to use only heim for Linux builds. This is now much easier to do since the 0.1 version of heim works fine for ARM. This is ideal since having to rely on two separate sources of data isn't the greatest if we can avoid it.
Sysinfo is still required for macOS and Windows, though. Temperature sensors do not work for those from heim, and for some reason, networks also don't work on Windows with heim...?
My personal CPU core calculation is also currently Linux-only, and as such, I'll still rely on sysinfo for Windows and macOS for now.
This isn't really a big optimization or anything btw. Just something I wanted to try.
Making some small changes that would hopefully improve performance a bit.
- Remove redundant string generations for CPU data conversion
- Switch to fnv for PID hashmap and hashsets
- Use buffered reading to avoid having to store too many lines as strings
