mirror of
https://github.com/ClementTsang/bottom.git
synced 2026-05-22 06:41:41 +00:00
ChrisJr404
1888dbb270
## 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>
Config JSON Schema
Generation
These are automatically generated from code using schemars. They're locked
behind a feature flag to avoid building unnecessary code for release builds, and you can generate them like so:
# Will print out to stdout
cargo run --features="generate_schema" -- --generate_schema
# e.g. for nightly
cargo run --features="generate_schema" -- --generate_schema > schema/nightly/bottom.json
# e.g. for a specific version
cargo run --features="generate_schema" -- --generate_schema 0.12.0 > schema/v0.12.0/bottom.json
Alternatively, run the scripts/schema/generate.sh script (for stable releases) or scripts/schema/nightly.sh
(for nightly), which does all of this for you.
Publication
To publish these schemas:
Stable
- Run
scripts/schema/generate.sh <YOUR_VERSION>. - Make a PR and merge it.
- Then, make a PR to schemastore to update the catalog. Here's an example of a PR.
Nightly
- Run
scripts/schema/nightly.sh. - Make a PR and merge it.