mirror of
https://github.com/ClementTsang/bottom.git
synced 2026-08-15 16:06:46 +00:00
ChrisJr404andClementTsang
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>
Extended Documentation
This is where the extended documentation resides, hosted on GitHub Pages. We use MkDocs, Material for MkDocs, and mike.
Documentation is currently built using Python 3.11, though it should work fine with older versions.
Running locally
One way is to just run serve.sh. Alternatively, the manual steps are, assuming your current working directory
is the bottom repo:
# Change directories to the documentation.
cd docs/
# Create and activate venv.
python -m venv venv
source venv/bin/activate
# Install requirements
pip install -r requirements.txt
# Run mkdocs
venv/bin/mkdocs serve
Deploying
Deploying is done via mike in order to get versioning. Typically, this is done through CI, but can be done manually if needed.
Nightly docs
cd docs
mike deploy nightly --push
Stable docs
cd docs
# Rename the previous stable version
mike retitle --push stable $OLD_STABLE_VERSION
# Set the newest version as the most recent stable version
mike deploy --push --update-aliases $RELEASE_VERSION stable
# Append a "(stable)" string to the end.
mike retitle --push $RELEASE_VERSION "$RELEASE_VERSION (stable)"