A bit of a followup to #449, this adds decimal places for values over 1GB in regards to disk usage. This affects the disk widget (for the read/write per second) and process widgets (total read, total write, read/write per second).
Removes/tweaks some really light colours that might cause issues with a white background. For example, yellow on white didn't look so great, so I adjusted the memory/rx colours for this mode.
This change adds a decimal + single digit to memory usage values over the 1 GiB threshold. Otherwise, there is no visible change.
(Note to self: implement the per-column width system soon, this change causes some values to potentially look a bit weird in mem-non-percent mode as it is if the value is really large, like 530.2GiB pushing right up against the column width, but it's currently tied to mem-percent mode. Ugh.)
Also revert a change made by accident where I switched to a decimal prefix system (GB) for memory values. This has been reverted back to a binary prefix (GiB).
For the process widget, we now sum the resource usage of the child processes on the parent entry when collapsing in tree mode.
Note that if you search to filter, and collapse, it will not sum the pruned values (values that cannot be seen). This is partly because I'm a bit lazy, and partly because I think this behaviour makes sense.
For example, let's say I search for a process with 4 child processes "AA, AB, BA, BB", with CPU usage 0.1, 0.2, 0.3, 0.4 respectively. Assume the parent process has 0 usage.
- Without filter, it sums to 1.0
- With a filter on A, it would sum to just 0.3
- With a filter on AA, it would sum to 0.1
I think this is fine because I'm treating this as summing any child that is still *visible* somehow. Summing unseen values would probably be weird as it would look like it's not adding up.
Further note that if you had, say, a child "CC" with a usage of, say, 2.0, and its parent of "AB", and you searched for CC in our above example, you would get a sum of 2.2. This is because AB is still visible by the fact that CC was the searched process, and AB must still exist (albeit faded out) in the tree hierarchy, and as such will still be displayed.
In particular, use non-binary prefixes for disk and memory usage in a process. Ideally everything is configurable by the user, but this is fine for now IMO until I can get around to doing in-app config.
Rewrite of the y-axis labeling and scaling for the network widget, along with more customization. This still has one step to be optimized (cache results so we don't have to recalculate the legend each time), but will be done in another PR for sake of this one being too large already.
Furthermore, this change adds linear interpolation at the 0 point in the case a data point shoots too far back - this seems to have lead to ugly gaps to the left of graphs in some cases, because the left hand limit was not big enough for the data point. We address this by grabbing values just outside the time range and linearly interpolating at the leftmost limit. This affects all graph widgets (CPU, mem, network).
This can be optimized, and will hopefully be prior to release in a separate change.
Adds users into the process widget (for Unix-based systems). This shows only in non-grouped modes, similar to state. Search is also supported.
In addition, a quick fix to prevent users from being in grouped mode when they tried to enter tree mode while grouped.
Two issues were highlighted as a result of using either Void Linux with disk encryption, or just disk encryption on Linux in general:
Two fixes:
1. Fixes a failed `usage()` call in the `get_disk_usage` function from failing the entire result. Now it only returns an entry with N/A results. This occurred in some distros and disk encryption setups, for example, the one for Void Linux here: https://docs.voidlinux.org/installation/guides/fde.html.
2. Fixes a potential mapping issue with disk encryption on Linux in general. Since the disk might map to `/dev/mapper/whatever`, but the I/O harvester was using another name, the mappings would not match. As such, we now also check if a symlink exists; if it does, then we take it and work out the correct path. This also fixes the disk name being wrong.
For consistency, we now don't automatically jump to the top of the list when using a sort shortcut. This behaviour already occurred with the sort menu and sorting by mouse clicks, so this is just now more consistent (and IMO less annoying, you can also always jump to the top via gg).
So it seems that tui-rs doesn't like rendering my CPU bars if the height is exactly 1. It needs at least 2. I have no idea why, this is probably something weird with how I render.
This, of course, breaks when there is only one row to report (i.e. with a dual core setup in #397).
The workaround switches the gap between the CPU and mem/net parts to 0, and increases the CPU's draw height by 1, only when the height is otherwise 1 (so the draw height is now at least 2). This does have the side effect of including an extra line to the side borders, but I think it's fine.
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`
Adds a new option in the config file to filter out network interfaces. Also add the option to filter by whole words.
Interface follows that of the existing ones:
```toml
[net_filter]
is_list_ignored = false
list = ["virbr0.*"]
regex = true
case_sensitive = false
whole_word = false
```
Fixes some performance regressions and forgotten cleanup.
Changes to attempt to improve performance to match 0.4.x:
- Remove `trace!` and `--debug` for now. These were a significant hog. Removing this dropped initial memory usage by about half.
- Add additional cleaning step for `pid_mapping` during process harvesting. This should hopefully improve memory usage as time goes on.
- Slightly change how we do sorting to hopefully be a bit more optimal? This was just an easy change to make that I spotted.
- Fix broken cleaning child thread task.
Adds a new flag, --mem_as_value (and its corresponding config option, mem_as_value = true), which defaults to showing process memory values by their amount rather than percentage.
Removes the random automatically generated colours for the CPU metrics. This was not supported in all terminal emulators, and would cause some of them to break (namely macOS Terminal).
Instead we'll default to colours we can be more certain will work and loop through them as required. Users can still override these colours with their own.
This was the cause of some process names getting cut off and looking weird for Linux (and Linux only, I'm not directly responsible for the other OSes).
This also adds spaces in between command line flags. Before, they were usually separated by either spaces (which looked fine) or null terminators (which meant it looked like something was broken).
Refactors tui-rs usage to the new 0.11.0 release. This release also fixes the highlighting bug from #249, and now, expanding a widget no longer overrides the widget title colour.
This commit also introduces #255, but that seems to be easy to bandaid so hopefully it will get fixed soon?