* feature: also check coretemp on Linux when gathering temps
* update changelog
* add comment
* add logic to check thermal zone if there are no hwmon entries
* cleanup
* handle duplicates between hwmon and thermal zone
* Revert "handle duplicates between hwmon and thermal zone"
This reverts commit 402606cc62f27ba196ef2ade6a669ae84aedf0e0.
* cleanup
* back to running thermal zone if no hwmon
* prevent failure cases
* temp logging
* name refactoring
* port dupe name logic to hwmon
* Cleanup, add fallback to sensor name
* more tests
* Fix log
* update changelog
* cleanup and more tests
* feature: show running time of processes
* fix clippy
* add time searching
* update changelog
* use safer duration for linux in case of 0
* some cleanup
* quick hack to deal with some Windows processes returning unix epoch time as start time
---------
Co-authored-by: Clement Tsang <34804052+ClementTsang@users.noreply.github.com>
* feature: add customizable process columns
* Add some tests and actual logic
* more tests
* update changelog
* update config field
* even more tests
* update documentation
* more testing
* other: add first draw immediately after initialization
Previously, I would only do the first draw after an event triggered, so
this just makes it so that I *always* draw once first. Some widgets look
a bit weird with no data, but this is fine I guess if we want to gain a
bit of responsiveness.
* other: potentially shorten first time to get data
* other: move event loop thread init earlier in app initialization
* First implementation of cache memory data collection, mostly copied from RAM and swap implementations
* First implementation of cache memory display, copied from RAM and swap implementations. placed cache as second in the list as it is more similar to the RAM than any other item in the list
* expanded comment to explain method.
* rustfmt
* all cache-related code excluded on windows, in the process refactored src/data_conversion.rs convert_mem_label() to convert a single label instead of all at once
* better factoring-out of cache memory logic to allow individual disabling
* added --enable_cache_memory flag, disabled cache memory collection by default
* renamed CCH to CHE
not sure how i messed that up
* changelog updated
* Added command line flag documentation
* updated config file documentation
* specified that buffer and cache memory display does not work on windows
* resolved merge conflicts
* added documentation to cache memory data collection
* capitalized Windows
* implemented missing canvas styling logic
* fixed misplaced no-windows flag
* reduced colour collisions, as cache colour was the same as the first GPU colour
* made FIFTH_COLOUR constant windows-only
* Revert "made FIFTH_COLOUR constant windows-only"
This reverts commit 72698f1dd7.
* made FIFTH_COLOUR constant non-windows-only
* minor fix for basic mode row count
* Update src/app/data_harvester/memory/sysinfo.rs
Co-authored-by: Clement Tsang <34804052+ClementTsang@users.noreply.github.com>
* Update src/canvas/widgets/mem_basic.rs
Co-authored-by: Clement Tsang <34804052+ClementTsang@users.noreply.github.com>
* updated default_config.toml
* formatting
---------
Co-authored-by: ClementTsang <34804052+ClementTsang@users.noreply.github.com>
Migrates existing heim-based disk data collection code off of it to either sysinfo or vendored code based on heim/sysinfo/other sources. This also allows us to remove heim completely from bottom.
---
* refactor: fix some refresh code
* remove async from the freebsd code
* some file/implementation organization
Turns out sysinfo lacks a lot of data I need. I can still use it for the
Windows disk usage implementation, but I'm probably going to manually
implement macos/linux usage and all io usage stats.
* more restructuring
* Some other fixes
* remove futures
* ready for some big changes?
* big changes
* linux io + reads
* use lossy conversion for mount point
* add windows refresh
* so long heim, and thanks for all the fish
* fix filter behaviour, remove string allocation when reading lines
* rename unix -> system for more accurate file struct representation
* fix freebsd
* port generic unix partition code
* add bindings and fix errors
* finish macOS bindings for I/O
* disable conform check, this seems to... make disk I/O work on macOS?????
* fix linux
* add safety comments
* more comments
* update changelog
* changelog
* We're going full 0.9.0 for this
* update lock
* fix some typing
* bleh
* some file management
* hoist out get_disk_usage
* fix some stuff for Windows
* typing and remove dead code allow lint
* unify typing
* fix
* fix 2
* macOS fix
* Add bindings file for windows
* add windows implementation
* fix macos
Since I have a macOS M1 laptop to test on now, I think it's a good time
to bump it to be officially supported, especially since it's going
to be the main macOS platform for the foreseeable feature.
* Revert "other: revert disk usage change for now (#962)"
This reverts commit d3661c2320.
* some cleanup
* update help menu
* update screenshot
* update changelog wording
* Remove redundant newlines
* Use type system to ensure help constants match in size
Denotes both usage and usage percentage. This also redoes the calculation for percentage to be based on the sum of avail + used, rather than on total, as otherwise we get potentially confusing percentages.
Pulls in the tui-rs grid logic so I can implement custom braille painting logic. We basically "flatten" the layering logic into a single layer by replacing resetting cells if the colour is different. This avoids the multiple allocations if we used multiple layers as intended with tui-rs.
This gives us chart results similar to the current stable version, but with a flamegraph similar to the current master branch.
This is a simple bug fix that changes the behaviour of a scroll select
(and column select) to only update if the updated position is _within_
the bounds of the list (0 to the max index, inclusive). Prior to this,
all the implementations but the disk implementation would just bound the
change. This was both inconsistent with the disk scroll state, but also
jarring since this meant a user could click on seemingly empty space but
it would somehow click on the very last entry.
This change also unifies the scroll calculation function between all the
scroll select functions. Ideally we get rid of the intermediary
functions but that might require more refactoring than I want for this
fairly simple bug fix.
The column select scroll calculation was also changed to fit this
behaviour, but it does not use the same logic as the other scroll
states. What could be done in the future is a generic implementation for
direction (or maybe just "increment vs. decrement") to share it all.
This changes various as_ref() calls as needed in order for bottom to successfully build in Rust beta 1.61, as they were causing type inference issues. These calls were either removed or changed to an alternative that does build (e.g. as_slice()).
Functionally, there should be no change.
For context, see:
- https://github.com/ClementTsang/bottom/issues/708
- https://github.com/rust-lang/rust/issues/96074
Adds page up/down scrolling support to respectively scroll up/down by a full page.
Note that this is mostly just to get the feature out for those interested, and is admittedly a bit rushed - I will be rewriting all logic involving event handling as part of state refactor anyways, so this will also get changed in the work done there, and therefore, I kinda just sped through this.
Addresses a potential case where processing would fail if there were missing values from the CPU line of `/proc/stat`, and allows it to successfully return.
Swap to manually calculating the mem total and usage via procfs. The usage calculation is now:
total - (free + cached + buffers + slab_reclaimable - shmem)
This follows the same usage calculation as htop. See the PR for more details.
Fixes the accuracy of the memory widget for Linux and macOS, and uses binary prefixes instead to be more accurate.
Regarding the first part, it turns out that the way I was calculating memory usage was *slightly* incorrect for a few reasons:
- Regarding macOS, it seems like the way I was determining usage (`usage = total - available`) is not the most accurate. The better way of doing this is apparently `usage = wire + active`, where `wire` is memory always marked to stay in RAM, and `active` is memory currently in RAM. This seems to be much closer to other applications now.
- Regarding Linux, this was somewhat due to two issues - one was that I should have used heim's own built-in function call to get how much memory was *used*, and the other is that when heim reads info from `meminfo`, it reads it in *kilobytes* - however, the values are actually in *kibibytes*. As such, to get the value in kibibytes, you want to actually take it in kilobytes.
While I've filed an issue for the library, for now, I'll just manually bandaid over this. See https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s2-proc-meminfo for more info.
Both changes take more advantage of platform-specific methods, and as such, the change unfortunately adds some ugly platform-specific code blocks.
Side note, Windows Task Manager apparently (?) uses binary prefixes for the values behind the scenes, but displays decimal prefixes. As such, now that we've switched to binary prefixes, it'll "seem" like the two aren't matching anymore since the units won't match, despite the values matching.
Fixes basic mode having broken click hitboxes (they were 1 unit too long in both directions). I'm pretty sure normal mode does too, but it's less noticeable due to bounding boxes.
This PR accomplishes two things:
1. This PR aims to add mount_filter to the config file. This allows a user to filter their disk widget entries by the mount name as well; this was particularly a problem in trying to address #431.
2. A slight rework of how the filter system works due to the need of being able to manage two potentially conflicting filter sources, since the disk widget will now potentially filter on both the disk name and the mount name.
In regards to the second point, the new behaviour is as such:
1. Is the entry allowed through any filter? That is, does it match an entry in a filter where is_list_ignored is false? If so, we always keep this entry.
2. Is the entry denied through any filter? That is, does it match an entry in a filter where is_list_ignored is true? If so, we always deny this entry.
3. Anything else is allowed.
This main (breaking) change is really the third point. This would mean that temp_filter and net_filter, when set to allow listed entries with is_list_ignored = false, are kinda... useless, as a whitelist in the scenario of being the only filter is kinda pointless. But hopefully this shouldn't be a problem...?
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).
