There was an if-condition that only ran if the sort state was false. But this would never be hit since `use_sort_table_value` always set it to false beforehand, so it would be stuck focusing on a hidden menu.
Wanted to prune Cargo.toml a tiny bit and noticed I could just use humantime to do this instead of time for logging purposes. Of course I still pull it in via Cargo.lock though.
A looooong time ago, we had to manually hijack stdio for FreeBSD to suppress a bogus stderr warning (see
#798). I filed an upstream report at GuillaumeGomez/sysinfo#875, but the real issue was actually with FreeBSD itself. From the upstream upstream bug report at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228432, it looks like this has been fixed since 2022 for FreeBSD 13, so I think it's safe to remove this hack at this point on our end, especially given that I don't build binaries for older than FreeBSD 13 anymore (oldest is 15 now).
This PR allows us to entirely remove the filedescriptor crate for FreeBSD since we no longer use it entirely.
I made the assumption that the max length of the comm field is 16 bytes. This is wrong though - it's now 64.
Note we may want to change it in the future to work regardless of potential length.
Because of the way I was initializing things, this caused it to report a huge spike at the start since it was doing a subtraction against 0. This fixes it by just using a hashmap (which also fixed another FIXME) and initializing the prev comparison structure on first view + skipping the first instance.
The bug would cause something like `(sd-pam)` to be missing, because what would happen is this:
1. We have something like `"123 ((sd-pam)) blah blah blah"`
2. We parse `start_paren` to be index 5.
3. We parse `end_paren` to be index 13.
4. Our `comm` is `"(sd-pam"`, and the rest of our string is `") blah blah blah"`... which is problematic, as then the rest of the parsing will be incorrect, and the entry gets rejected!
Deals with a possible issue with kitty and its `cursor_trail` functionality, where it supposedly does a bit of extra calculation work when the cursor's location after drawing is too far from the previous location when kitty is checking whether it should recalculate things for the trail, even if the cursor is hidden (at least this is my guess by looking around in https://github.com/kovidgoyal/kitty/blob/c1d507dbe8cd12830d8b97b0d350d9dc2e4d383f/kitty/cursor_trail.c). The fix is (apparently) to just park the cursor at the origin after drawing each time, and this seemingly helps as a workaround.
If this is right (and it very well could be wrong, I'm making a guess here), IMO the actual fix is that kitty should _probably_ skip cursor trail calculation work if the cursor is hidden I guess?
This change should fix the issue around `cargo install` being confused by the schema generation binary by just moving it entirely into a separate tool "crate".
Fixes a bug with cgroups v1, where the "total" if there isn't a limit set may be some crazy high number which would be interpreted as many terabytes large. This is obviously incorrect, so we should not use that as the total, and instead, use the min of the actual total and the cgroups value (so if a lower cgroup v1 value is set, we use that instead).
This PR adds ufs disk io counters on freebsd by using sysinfo. This PR also updates the Cargo.toml to use the dep syntax for the unused feature flags starship-battery and nvml-wrapper.
Comment out flags header in default config file + fix bug causing deprecated warnings if `[flags]` was uncommented even when the fields themselves were commented out.
This change moves some options to a more appropriate section for the config file. This only deprecates the old options for now, so they're still valid, but we will remove them later (maybe after the next stable release, to give warning).
One thing I want to do for the legend position options is maybe expand it, and now is the best time to do so, but for now I'm just copying it over verbatim.
The deprecated options will also emit a warning to stderr.
This PR also contains a driveby to alias `[network]` to `[network_graph]`.
This refactor unifies the draw and state logic for the time series graph
"components" - things that we build bottom widgets out of. In this case,
it's just the time series graphs, which things like the temperature graph,
network graph, memory usage graph, and cpu graph use.
This is a pretty big refactor in terms of things moved around, but
functionality-wise there is no change.
<!-- Please use this template (unless you have a very good reason not
to). PRs that do not use the template may be closed. -->
## Description
_A description of the change, what it does, and why it was made. If
relevant (e.g. UI changes), **please also provide
screenshots/recordings**:_
Rename a bunch of code/struct field names to use "colour". Note this
should have no functional change to config settings as I was already
aliasing "colour" for "color" settings, this just flips it internally.
As for why, I'm Canadian, I grew up spelling it this way, sorry.
## Issue
_If applicable, what issue does this address?_
Closes: #<issue-number>
## Testing
_If relevant, please state how this was tested (including steps):_
_If this change affects the program, please also indicate which
platforms were tested:_
- [ ] _Windows_
- [ ] _macOS (specify version below)_
- [x] _Linux (specify distro below)_
- [ ] _Other (specify below)_
## Checklist
_Ensure **all** of these are met:_
- [x] _If this PR adds or changes a dependency, please justify this in
the description_
- [x] _If this is a code change, areas your change affects have been
linted using (`cargo fmt`)_
- [x] _If this is a code change, your changes pass `cargo clippy --all
-- -D warnings`_
- [x] _If this is a code change, new tests were added if relevant_
- [x] _If this is a code change, your changes pass `cargo test`_
- [x] _The change has been tested to work (see above) and doesn't appear
to break other things_
- [x] _Documentation has been updated if needed (`README.md`, help menu,
docs, configs, etc.)_
- [x] _There are no merge conflicts_
- [x] _You have reviewed your changes first_
- [x] _The pull request passes the provided CI pipeline_
## Other
_Anything else that maintainers should know about this PR:_
## Description
You can now tell bottom which column the process widget should be sorted
by at startup, instead of always falling back to CPU%.
It's settable in two places: a `default_sort` field under `[processes]`
in the config file, and a `--process_default_sort` CLI flag. The flag
accepts the same column-name aliases that already work in
`[processes].columns` (e.g. `cpu%`, `mem`, `pid`, `name`, `read`,
`t.write`, etc.), and the CLI flag wins over the config setting.
```toml
[processes]
default_sort = "mem"
```
```
btm --process_default_sort mem
```
This piggybacks on the same wiring that #2003 added for the disk and
temperature widgets, just routed through the existing `ProcTableConfig`
so the widget initializer can pick a non-default sort index without
touching any of the runtime sort code.
A few small things worth flagging:
- If the configured column is not actually present in the user's
`columns` list, the widget falls back to the existing default behaviour
(CPU% in normal/grouped mode, PID in tree mode) instead of silently
snapping to column 0. That keeps misconfiguration predictable.
- The deserializer for `ProcColumn` was refactored to share its parsing
with the CLI's value parser, so config-file and CLI accept the exact
same aliases. The set of accepted strings is unchanged from before.
I checked the `# columns =` workaround floating around in #810 and on
Stack Overflow; it changes layout but not the sort key, so it doesn't
actually solve the original ask.
## Issue
Closes: #810
## Testing
_If this change affects the program, please also indicate which
platforms were tested:_
- [ ] _Windows_
- [ ] _macOS (specify version below)_
- [x] _Linux (Kali, kernel 6.19)_
- [ ] _Other (specify below)_
Added unit tests for `ProcWidgetState::new` covering the happy path
(sort index actually lands on the configured column) and the fallback
path (configured column not in the column list). Also added valid +
invalid config integration tests under `tests/valid_configs/` and
`tests/invalid_configs/`, matching the pattern used for the disk/temp
default-sort tests.
`cargo test`, `cargo clippy --all -- -D warnings`, and `cargo fmt
--check` are all clean.
Manual smoke test: ran `btm --process_default_sort=mem` and `btm
--process_default_sort=garbage`. The first starts the widget sorted by
Mem%, the second exits early with `'garbage' is not a valid process
column for --process_default_sort` from the args layer. Also ran `btm -C
tests/valid_configs/proc_default_sort.toml` to confirm the config-file
path works the same way.
## Checklist
_Ensure **all** of these are met:_
- [x] _If this PR adds or changes a dependency, please justify this in
the description_ (no new deps)
- [x] _If this is a code change, areas your change affects have been
linted using (`cargo fmt`)_
- [x] _If this is a code change, your changes pass `cargo clippy --all
-- -D warnings`_
- [x] _If this is a code change, new tests were added if relevant_
- [x] _If this is a code change, your changes pass `cargo test`_
- [x] _The change has been tested to work (see above) and doesn't appear
to break other things_
- [x] _Documentation has been updated if needed (`README.md`, help menu,
docs, configs, etc.)_
- [x] _There are no merge conflicts_
- [x] _You have reviewed your changes first_
- [x] _The pull request passes the provided CI pipeline_
## Other
The schema under `schema/nightly/bottom.json` was regenerated via `cargo
run --features generate_schema --bin schema`; the only diff is the new
`default_sort` entry on `ProcessesConfig`, mirroring what's already
there on `DiskConfig` and `TemperatureConfig`.
---------
Co-authored-by: ClementTsang <dev@cjhtsang.ca>
Add support for a temperature graph widget. Quick-and-dirty implementation for now, will clean this up with other widgets later (maybe after adding a disk graph widget).
Clement Tsang