clementtsang / bottom

Yet another cross-platform graphical process/system monitor.

bottom

A customizable cross-platform graphical process/system monitor for the terminal.
Supports Linux, macOS, and Windows. Inspired by gtop, gotop, and htop.

_{Demo using the Gruvbox theme (--color gruvbox), along with IBM Plex Mono and Kitty}

Table of contents

• Features
• Support
  • Official
  • Unofficial
• Installation
  • Cargo
  • Arch Linux
  • Debian / Ubuntu
  • Exherbo Linux
  • Fedora / CentOS / AlmaLinux / Rocky Linux
  • Gentoo
  • Nix
  • Solus
  • Snap
  • Void
  • Homebrew
  • MacPorts
  • Chocolatey
  • Scoop
  • winget
  • Windows installer
  • Manual installation
  • Binaries
    • Auto-completion
• Usage
• Configuration
• Troubleshooting
• Contribution
  • Contributors
• Thanks

Features

As (yet another) process/system visualization and management application, bottom supports the typical features:

• Graphical visualization widgets for:

  • CPU usage over time, at an average and per-core level
  • RAM and swap usage over time
  • Network I/O usage over time

  with support for zooming in/out the current time interval displayed.

• Widgets for displaying info about:

  • Disk capacity/usage
  • Temperature sensors
  • Battery usage

• A process widget for displaying, sorting, and searching info about processes, as well as support for:

  • Kill signals
  • Tree mode

• Cross-platform support for Linux, macOS, and Windows, with more planned in the future.

• Customizable behaviour that can be controlled with command-line options or a config file, such as:

  • Custom and built-in colour themes
  • Customizing widget behaviour
  • Changing the layout of widgets
  • Filtering out entries in some widgets

• Some other nice stuff, like:

  • An htop-inspired basic mode
  • Expansion, which focuses on just one widget

• And more!

You can find more details in the documentation.

Support

Official

bottom officially supports the following operating systems and corresponding architectures:

• macOS (x86_64, aarch64)
• Linux (x86_64, i686, aarch64)
• Windows (x86_64, i686)

These platforms are tested to work for the most part and issues on these platforms will be fixed if possible. Furthermore, binaries are built and tested using the most recent version of stable Rust at the time.

For more details on supported platforms and known problems, check out the documentation.

Unofficial

bottom may work on a number of platforms that aren't officially supported. Note that unsupported platforms:

• Might not be tested in CI to build or pass tests (see here for checked platforms).
• Might not be properly tested by maintainers prior to a stable release.
• May only receive limited support, such as missing features or bugs that may not be fixed.

Note that some unsupported platforms may eventually be officially supported (e.g., FreeBSD).

A non-comprehensive list of some currently unofficially supported platforms that may compile/work include:

• FreeBSD (x86_64)
• Linux (armv6, armv7, powerpc64le, riscv64gc)
• Android (arm64)

For more details on unsupported platforms and known problems, check out the documentation.

Installation

Cargo

Installation via cargo can be done by installing the bottom crate:

# You might need to update the stable version of Rust first.
# Other versions might work, but this is not guaranteed.
rustup update stable

# Install the binary from crates.io.
cargo install bottom --locked

# If you use another channel by default, you can specify
# the what channel to use like so:
cargo +stable install bottom --locked

# --locked may be omitted if you wish to not use the
# locked crate versions in Cargo.lock. However, be
# aware that this may cause problems with dependencies.
cargo install bottom

Arch Linux

bottom is available as an official package that can be installed with pacman:

sudo pacman -S bottom

If you want the latest changes that are not yet stable, you can also install bottom-git from the AUR. For example, to install with paru:

sudo paru -S bottom-git

Debian / Ubuntu

A .deb file is provided on each stable release and nightly builds for x86, aarch64, and armv7 (note stable ARM builds are only available for 0.6.8 and later). An example of installing this way:

# x86-64
curl -LO https://github.com/ClementTsang/bottom/releases/download/0.9.6/bottom_0.9.6_amd64.deb
sudo dpkg -i bottom_0.9.6_amd64.deb

# ARM64
curl -LO https://github.com/ClementTsang/bottom/releases/download/0.9.6/bottom_0.9.6_arm64.deb
sudo dpkg -i bottom_0.9.6_arm64.deb

# ARM
curl -LO https://github.com/ClementTsang/bottom/releases/download/0.9.6/bottom_0.9.6_armhf.deb
sudo dpkg -i bottom_0.9.6_armhf.deb

Exherbo Linux

bottom is available as a rust package that can be installed with cave:

cave resolve -x repository/rust
cave resolve -x bottom

Fedora / CentOS / AlmaLinux / Rocky Linux

bottom is available in COPR:

sudo dnf copr enable atim/bottom -y
sudo dnf install bottom

.rpm files are also generated (starting from 0.9.3) for x86. If you wish to install this way, then you can do something like:

# x86-64
curl -LO https://github.com/ClementTsang/bottom/releases/download/0.9.6/bottom-0.9.6-1.x86_64.rpm
sudo rpm -i bottom-0.9.6-1.x86_64.rpm

# Nightly x86-64
curl -LO https://github.com/ClementTsang/bottom/releases/download/nightly/bottom-0.9.6-1.x86_64.rpm
sudo rpm -i bottom-0.9.6-1.x86_64.rpm

Gentoo

Available in the official Gentoo repo:

sudo emerge --ask sys-process/bottom

Nix

Available in the nix-community repo:

nix-env -i bottom

Solus

Available in the Solus repos:

sudo eopkg it bottom

Snap

bottom is available as a snap:

sudo snap install bottom

# To allow the program to run as intended
sudo snap connect bottom:mount-observe
sudo snap connect bottom:hardware-observe
sudo snap connect bottom:system-observe
sudo snap connect bottom:process-control

Void

Available in the void-packages repo:

sudo xbps-install bottom

Homebrew

Formula available here:

brew install bottom

MacPorts

Available here:

sudo port selfupdate
sudo port install bottom

Chocolatey

Chocolatey packages are located here:

choco install bottom

Scoop

Available in the Main bucket:

scoop install bottom

winget

The winget package can be found here:

winget install bottom

# If you need a more specific app id:
winget install Clement.bottom

You can uninstall via Control Panel, Options, or winget --uninstall bottom.

Windows installer

You can also manually install bottom as a Windows program by going to the latest release and installing via the .msi file.

Manual installation

There are a few ways to go about doing this manually. Note that you probably want to do so using the most recent version of stable Rust, which is how the binaries are built:

# You might need to update the stable version of Rust first.
# Other versions might work, but this is not guaranteed.
rustup update stable

# Option 1 - Download from releases and install
curl -LO https://github.com/ClementTsang/bottom/archive/0.9.6.tar.gz
tar -xzvf 0.9.6.tar.gz
cargo install --path . --locked

# Option 2 - Clone the repo and install manually
git clone https://github.com/ClementTsang/bottom
cd bottom
cargo install --path . --locked

# Option 3 - Clone and install directly from the repo all via Cargo
cargo install --git https://github.com/ClementTsang/bottom --locked

# You can also pass in the target-cpu=native flag for
# better CPU-specific optimizations. For example:
RUSTFLAGS="-C target-cpu=native" cargo install --path . --locked

Binaries

You can also use the pre-built release binaries manually:

• Latest stable release, built using the release branch
• Latest nightly release, built using the main branch at 00:00 UTC daily

To use, download and extract the binary that matches your system. You can then run by doing:

./btm

or by installing to your system following whatever the procedure is for installing a binary to your system.

Auto-completion

The release binaries are packaged with shell auto-completion files for bash, fish, zsh, and Powershell. To install them:

• For bash, move btm.bash to $XDG_CONFIG_HOME/bash_completion or /etc/bash_completion.d/.
• For fish, move btm.fish to $HOME/.config/fish/completions/.
• For zsh, move _btm to one of your $fpath directories.
• For PowerShell, add _btm.ps1 to your PowerShell profile.

The individual auto-completion files are also included in the stable/nightly releases as completion.tar.gz.

Usage

You can run bottom using btm.

• For help on flags, use btm -h for a quick overview or btm --help for more details.
• For info on key and mouse bindings, press ? inside bottom or refer to the documentation.

You can find more information on usage in the documentation.

Configuration

bottom accepts a number of command-line arguments to change the behaviour of the application as desired. Additionally, bottom will automatically generate a configuration file on the first launch, which one can change as appropriate.

More details on configuration can be found in the documentation.

Troubleshooting

If some things aren't working, give the troubleshooting page a look. If things still aren't working, then consider opening a question or filing a bug report.

Contribution

Whether it's reporting bugs, suggesting features, maintaining packages, or submitting a PR, contribution is always welcome! Please read CONTRIBUTING.md for details on how to contribute to bottom.

Contributors

Thanks to all contributors:

Marcin Wojnarowski 💻 📦	Mahmoud Al-Qudsi 💻	Andy 💻	Kim Brose 💻	Sven-Hendrik Haase 📖	Artem Polishchuk 📦 📖	Trung Lê 📦 🚇
dm9pZCAq 📦 📖	Lukas Rysavy 💻	Erlend Hamberg 💻	Frederick Zhang 💻	pvanheus 💻	Zeb Piasecki 💻	Brian Di Palma 📖
Lasha Kanteladze 📖	Herby Gillot 📖	Greg Brown 💻	TotalCaesar659 📖	George Rawlinson 📖 📦	adiabatic 📖	Randy Barlow 💻
Patrick Jackson 🤔 📖	Mateusz Mikuła 💻	Guillaume Gomez 💻	shura 💻	Wesley Moore 💻	xgdgsc 📖	ViridiCanis 💻
Justin Martin 💻 📖	Diana 💻	Hervy Qurrotul Ainur Rozi 📖	Mike Rivnak 📖	lroobrou 💻	database64128 💻	Chon Sou 💻
DrSheppard 📖	Rareș Constantin 💻	felipesuri 📖	spital 💻	Michael Bikovitsky 💻	Dmitry Valter 💻	Twan Stok 💻
Yuxuan Shui 💻	Wenqing Zong 💻	Gabriele Belluardo 💻	Zeb Piasecki 💻	wzy 💻 📖	john-s-lin 📖	Lee Wonjoon 💻 📖
David Legrand 📖	Michal Bryxí 📖	Raphael Erik Hviding 💻

Thanks

• This project is very much inspired by gotop, gtop, and htop.

• This application was written with many, many libraries, and built on the work of many talented people. This application would be impossible without their work. I used to thank them all individually but the list got too large...

• And of course, another round of thanks to all the contributors and package maintainers!

bottom's Issues

Make the help dialog box scrollable and switch to using tabs

Describe the feature request

Why should we consider this feature request? Describe why, and/or how you think this feature will solve the issue, or overall improve the application:

EDIT: now two parts:

1. Since help can wrap and entry size can go on for a bit, making it scrollable would solve the issue of potentially overflowing.

2. More of an addendum since we're going to work with the dialog box anyways. tui-rs comes with tabs; we can use that to our advantage instead of our current tab system.

Additional context/details

Provide any additional context or details here. What needs to be done, why, etc:

A good example of how to do the scrolling this is ncdu. The procedure would probably be as follows:

• Add a scroll state to app state. This doesn't have to use the bar system we use on others, we can just read it like a ticker tape (up and down scroll up/down how much is seen regardless, no bar

• Canvas will ofc need to display this somehow. Use arrows to display (and hide if at border).

• May need to play around with canvas widths too in the end.

In regards to tabs, this is more of a side suggestion.

Add colour name (at least default colours) and RGB support in config

Describe the feature request

Inspired by spotify-tui. Adding default colour options (so default ones supported by TUI) and RGB would be a nice alternative to the current hex implementation we have now.

Additional context

Provide any additional context here.

Give the option to allow viewing network by interface rather than only showing grouped data

Describe the feature request

Why should we consider this feature request? Describe why, and/or how you think this feature will solve the issue, or overall improve the application:

Currently we grab networks and sum them together as a lump sum. RX, TX, etc. are all a summation of all interfaces.

We also already grab that data, we just toss away the individual data when we collect it and merge it all together.

This would be a config/flag feature. Toggling within app might also be possible but eh, then we would have to collect and save both total and separate data.

Additional context/details

Provide any additional context or details here. What needs to be done, why, etc:

Give alternative keybinds for Alt-* for macOS users

Describe the feature request

Alt doesn't exist, so alt-* won't work!

Ideally we give Command-based ones but that doesn't seem to be supported by Crossterm as of now.

Additional context/details

Provide any additional context or details here. What needs to be done, why, etc.

Reword parts of the README/documentation before release

This is probably something that will take a while.

I currently feel like the README and overall documentation is... kinda poorly put together. Like someone just repeatedly piled stuff on top of everything with nary a thought. Because that's exactly what's happened while I was developing this.

So... yeah I should probably take some time to go over the documentation.

Ensure new Travis config works...

The Travis config has been changed a ton since 0.2.1; it will need to be tested again to make sure the releases part works...

Been tested due to 0.2.2. Will need to figure out 32-bit linux though.

Auto-build releases if possible

• AUR
• Choco
• Homebrew

---

To address this:

• Probably include the base AUR/Choco/Homebrew/etc. files into the repo. On release builds, automatically fill in the fields as appropriate (might have to write a simple script for this) and release them alongside the other files (for cases like AUR, Choco) or directly deploy them (Homebrew).

  Alternatively, keep the files in their own repos (which all three cases here already are) and pull them to edit rather than bundling the files alongside here.

Allow disabling borders

Describe the feature request

Allow (via config and flag) disabling widget borders to save space. Easy to do via tui-rs afaik.

May need to investigate how much this will actually help though.

Additional context/details

Thank you /u/the_gnarts for the idea!

IO stats per process

Hi! It would be nice if btm displayed & could sort process per IO:
for example, say when 'entering' the full screen processes' view.
Such would eliminate the need of firing up a secondary terminal with iotop...

Reason i mentioned the full screen processes' view,
is simply because there currently exists lots of 'free estate' there,
and thereby things wouldn't look clunky & overcrowded,
on the standard 'default' view with all the widgets on display.
That's just a (hopefully not silly) idea for possible design...

zenith, is another Rust-written program inspired by htop/gotop etc:
that's pretty much where the idea above came to mind,
for suggesting the addition of per-process iotop stats...

Hopefully i'm not annoying you with the above request in the first place,
and you'll consider something among those lines at some point down the road...
All the best!

Ignore certain characters in search

Describe the bug

Some characters aren't ignored by the process search. For example, caps lock in windows is counted for some reason.

To reproduce

Steps on how to reproduce the behaviour:

1. Go search.
2. Press caps lock.
3. Search is now "populated".

Screenshots

If applicable, add screenshots to help explain your problem.

Platform

Provide information on:

• OS: Windows
• Terminal: Powershell

Additional context

If anything hasn't been covered by the above categories, state it down here.

Last pass for 0.3.0 - refactor/fix/improve

Describe the chore

What is it that needs to be done? If relevant, say why:

Definitely a good idea to go through all the things added/changed and see what's changeable to improve the final release.

Things I'm currently looking for:

• Unneeded unwraps. There's only 3 IIRC.

• Any inefficient code. My main concern is CPU usage; I honestly feel that it's too high sometimes.

• Reduce clones and to_strings if possible.

• Any refactoring if it will end up making the code look better. Reducing reused lines, less giant structs, that sort of stuff.

• Switch to a nicer pattern for how we initialize config + flag settings. This is pretty ugly rn.

Populate a default config file

Describe the feature request

Perhaps it is a good idea to create a default config file (same as the one that is bundled into release) in the config path (as specified here) if it does not exist?

Additional context/details

Why it would be beneficial:

• no more need for bundling the default config file with a release (single executable ftw)
• the config file will anyways end up in this path, so why not put it automatically
• easier to get started, just run btm once and you can go straight to configuring with lets say vim ~/.config/bottom/bottom.toml

Allow yanking of data.

Describe the feature request

Might be of interest to some users? Seems like an interesting idea IMO to allow a user to instantly pull data to clipboard if they want it.

Additional context

Provide any additional context here.

Default config path doesn't actually work on Unix like.

Should be simple to fix, will fix and immediately update.

Issue with arrow characters in Terminator

Describe the bug

A clear and concise description of what the bug is and what the expected behaviour was:

Courtesy of Shootertrex:

On Terminator, the right half of the triangle didn't repaint until the terminal was resized (half pointed up, half pointed down and vice versa).

To reproduce

Steps on how to reproduce the behaviour:

1. Try sorting
2. Character doesn't properly redraw

Screenshots

If applicable, add screenshots to help explain your problem:

Platform

Provide information on:

Operating System: OpenSUSE Tumbleweed

Terminal: Terminator

Any other relevant information (more details are always good!):

Additional context

If anything hasn't been covered by the above categories, state it down here:

I personally cannot reproduce for now... will have to look into trying to do that and proceed from there. It's possible this is an issue that I can't solve, so reproduction is going to have to be the first step.

Update basic testing, add for invalid config files

Update and add to our basic tests that just check for invalid flags.

• Update flag test for flags that take in a value

• Add tests for conflicting flags

• Add config files that have invalid entries and test against them

Fix basic bar for some sizes

Describe the bug

A clear and concise description of what the bug is and what the expected behaviour was. If applicable, add screenshots to help explain your problem:

To reproduce

Steps on how to reproduce the behaviour:

1. Open in a small window with basic mode on.

Platform

If relevant, please provide information on:

Operating System:

Terminal:

Shell:

Any other relevant information (more details are always good!):

Additional context

If anything hasn't been covered by the above categories, state it down here:

Arrow icon looks strange on kitty terminal on macOS Catalina

Describe the bug

A clear and concise description of what the bug is and what the expected behaviour was:

Arrow icon looks like a line on macOS.

May be related to #42?

To reproduce

Steps on how to reproduce the behaviour:

1. Open btm on macOS with kitty
2. Arrows show up as lines.

Screenshots

If applicable, add screenshots to help explain your problem:

Platform

If relevant, please provide information on:

Operating System: macOS Catalina

Terminal: Kitty

Shell: zsh

Any other relevant information (more details are always good!):

Additional context

If anything hasn't been covered by the above categories, state it down here:

Laptop Mode

Describe the feature request

If the machine btm is running on has a battery, show additional information that is most vital to the users of portable computers, namely:

1. charge status in percent
2. time till full or empty, depending on whether the machine is connected to power
3. current amount of power consumption watts

Right now I have to use battop for this usecase, which comes with a 'big' TUI with a lot of additional information that is not that useful in practice. It's more of a demo for the underlying library displaying all the information there is about batteries.

Additional context

I love btm for…

• …being configurable
• …being controllable with hotkeys
• …having all the information I could ask for

For me this already replaces bandwhich and the MacOS Activity Monitor, which has terrible performance.

With the integration of battery information, btm is the single go-to place to see what's going on with the machine.

Here is the information I usually look at in battop:

Technical Notes

• it looks like on MacOS at least, the OS only provides new battery information every half a minute or so. I usually launch battop with -d 10, to refresh only every 10 seconds.

Cannot compile v0.2.1: cannot find derive macro Deserialize in this scope

Describe the bug

cargo install bottom leads to a compilation error where Deserialize is not in scope. Maybe a missing feature?

   Compiling bottom v0.2.1
error: cannot find derive macro `Deserialize` in this scope
  --> /home/dumontj/.cargo/registry/src/github.com-1ecc6299db9ec823/bottom-0.2.1/src/main.rs:59:19
   |
59 | #[derive(Default, Deserialize)]
   |                   ^^^^^^^^^^^

error: cannot find derive macro `Deserialize` in this scope
  --> /home/dumontj/.cargo/registry/src/github.com-1ecc6299db9ec823/bottom-0.2.1/src/main.rs:65:19
   |
65 | #[derive(Default, Deserialize)]
   |                   ^^^^^^^^^^^

error: cannot find derive macro `Deserialize` in this scope
  --> /home/dumontj/.cargo/registry/src/github.com-1ecc6299db9ec823/bottom-0.2.1/src/main.rs:82:19
   |
82 | #[derive(Default, Deserialize)]
   |                   ^^^^^^^^^^^

error[E0277]: the trait bound `Config: serde::de::Deserialize<'_>` is not satisfied
   --> /home/dumontj/.cargo/registry/src/github.com-1ecc6299db9ec823/bottom-0.2.1/src/main.rs:432:6
    |
432 |         Ok(toml::from_str(config_str.as_str())?)
    |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `serde::de::Deserialize<'_>` is not implemented for `Config`
    | 
   ::: /home/dumontj/.cargo/registry/src/github.com-1ecc6299db9ec823/toml-0.5.6/src/de.rs:77:8
    |
77  |     T: de::Deserialize<'de>,
    |        -------------------- required by this bound in `toml::de::from_str`

error: aborting due to 4 previous errors

To reproduce

Steps on how to reproduce the behaviour:

1. cargo install bottom

Platform

Provide information on:

Operating System: Red Hat Enterprise Linux 7

Terminal: bash

WSL ubuntu: thread '<unnamed>' panicked at 'index out of bounds

Describe the bug

run btm and got this error:
thread '' panicked at 'index out of bounds: the len is 1170 but the index is 4611686018427387991', /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libcore/slice/mod.rs:2812:14
0:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12: __libc_start_main
13:

To reproduce

install the .deb as written in the doc then run btm

Platform

Operating System:
windows 10 with WSL Ubuntu 18.04

Terminal:
Windows Terminal 0.10.761.0

Shell:
ZSH

Add warning if screen too small

Describe the feature request

This is mostly inspired by ncdu; this is mostly just a warning to give to state that items might be hidden completely from view and unusable.

Additional context

Provide any additional context here.

Time scaling

Describe the feature request

This should support time scaling (to a reasonable degree). 3 minutes is fine IMO, maybe bump to 5. Scroll wheel on graph to scale, probably?

Will require adding support for more widget positions in app.

Additional context

Provide any additional context here.

• +/- key and mouse support
• how are we indicating time range? Add back a scale?

Capital letters broken on powershell on Windows

Describe the bug

Searching then trying to use uppercase letters is broken. Seems to only affect Windows...

To reproduce

Steps on how to reproduce the behaviour:

1. Open btm on powershell
2. Try to search with something like "FIREFOX"

Screenshots

If applicable, add screenshots to help explain your problem.

Platform

Provide information on:

OS: Windows
Terminal: Powershell

Additional context

If anything hasn't been covered by the above categories, state it down here.

typo fails build with yay

Question

installing using yay throws an error due to a character that gets included in a link
error: failed to get 200 response from https://crates.io/api/v1/crates/regex/1.3.5/download, got 502
please remove the "`" next update for qol

I would like to transfer ownership of AUR package "bottom-bin"

@ClementTsang Are you xoronth in aur.archlinux.org? Are you willing to maintain bottom-bin? I'd like to have less job in my hand to deal with.

Add more filtering options

Describe the feature request

Why should we consider this feature request? Describe why, and/or how you think this feature will solve the issue, or overall improve the application:

More filtering options could be nice. For example, allow filtering things so we only see processes that are >1% CPU usage.

Additional context/details

Provide any additional context or details here. What needs to be done, why, etc:

Adding this might require rethinking how we currently deal with searching by x category. Since we currently only have two categories - PID and name - it's easy, just make TAB a toggle.

This changes if we add multiple search categories. How do we manage which thing we're searching? Do we stay backwards-compatible? Or just replace it with an entirely new system? (I'm leaning towards the latter tbh)

• One possible idea (that I personally don't really like but it's the easiest) is we search based on some prefix. Want CPU% filtering? Do some query like cpu%<5. This is similar to how top does it. Why don't I like it? I think it's too verbose, personally, and maybe unintuitive?

• Another is to add some kinda TUI selector within the search bar to allow for specific types of searching for each category. So for example, ctrl-c gives CPU , ctrl-m gives memory, etc. This is probably one of the better ways (IMO). Would need some redesigning of the search bar though as it might be too unintuitive? Unless I literally show all hotkeys there. Also, I'm starting to overload the whole ctrl-x space so that might be a thing to consider.

• Just make tab and ctrl-tab to cycle through. Easy to do I guess but might be kinda dumb tbh? idk.

Colouring of total rx/tx

Describe the feature request

Add colouring options + colours overall to total rx/tx

Additional context

Provide any additional context here.

Sorting icons not displaying properly

Describe the bug

The arrows used to indicate that a column has been sorted does not fully appear.

To reproduce

1. Start bottom
2. Sort a process column e.g. cpu

Screenshots

Platform

Operating System:

OpenSUSE Tumbleweed

Terminal:

Konsole

Shell:

bash 5.0.11

Additional Details:

On another computer using Terminator (also bash), a similar issue happened, but the right half of the triangle didn't repaint until the terminal was resized (half pointed up, half pointed down and vice versa). Unfortunately I don't have screenshots of it.

Crashing issue with too small windows

There's an issue with the app straight up crashing on start/during loading if the window gets too small

Allow hiding certain blocks according to user preference

Describe the feature request

Allow hiding certain blocks according to user preference through command line flags

Additional context/details

Sometimes you may not need to see disk, network blocks (need a something minimal)

Y-scaling in graphs

Describe the feature request

Why should we consider this feature request? Describe why, and/or how you think this feature will solve the issue, or overall improve the application:

I've already added time-scaling. Next would be to add y-scaling (or at least it would be an interesting idea).

Some potential issues might be how we can do the UI properly... for example, how to we allow a user to control which region we zoom into? Time is easy, since we effectively force one anchor point (time 0s) and just go back however much we want to zoom in/out from there.

To be honest this might also make most sense for networks only, and less for cpu/memory (which are percent based), though this might change if we also add temp+disk graphing capabilities.

Additional context/details

Provide any additional context or details here. What needs to be done, why, etc:

Cursor currently can go off screen without repositioning.

Describe the bug

A clear and concise description of what the bug is and what the expected behaviour was:

Due to us not repositioning to where the cursor is, if you put a huge query and scroll left, it will not automatically redraw to where the cursor is.

To reproduce

Steps on how to reproduce the behaviour:

1. Type in a huge message
2. Scroll left until you go off screen

Screenshots

If applicable, add screenshots to help explain your problem:

Platform

Provide information on:

Operating System: AL

Terminal: Kitty

Any other relevant information (more details are always good!):

Additional context

If anything hasn't been covered by the above categories, state it down here:

Investigate whether there's a better way to do input events

Describe the chore

What is it that needs to be done? If relevant, say why:

I put this as a chore as this task is really more for research on whether we can do it (and how) before actually going forward with an implementation. If a way is doable then open another ticket with how we can do this as an enhancement.

One of the problems is that scrolling in particular is a CPU hog. This is because each scroll action will force a COMPLETE redraw to reflect the scroll (I've tested and redrawing is the cause). This is particularly noticeable with mice like MX Masters which can scroll at stupidly high rates.

Currently what is done instead is there's a 20ms limiter to prevent too many events clogging up and redrawing. However, it's still pretty... eh as a solution.

Scrolling in tables doesn't work very well if you resize the draw area

Scrolling in tables doesn't work very well if you resize the draw area, where there is enough room to draw more entries, but it won't until you scroll up. This is due to scroll logic; I'm aware of the issue and will fix this in a future update.

For now the workaround is to just scroll up. For expansion, I'm just resetting scroll positions for now.

Fix issue with resizing and scrolling... again

Describe the bug

A clear and concise description of what the bug is and what the expected behaviour was. If applicable, add screenshots to help explain your problem:

If you resize too small, then scroll, then resize larger, the resulting list is incorrect.

To reproduce

Steps on how to reproduce the behaviour:

1. Resize to a small window with few entries
2. Scroll down or up
3. Upsize

Platform

If relevant, please provide information on:

Operating System:

Terminal:

Shell:

Any other relevant information (more details are always good!):

Additional context

If anything hasn't been covered by the above categories, state it down here:

Modularity with widget placement

Describe the feature request

Why should we consider this feature request? Describe why, and/or how you think this feature will solve the issue, or overall improve the application:

Some people might not like the default placement of widgets that I provide. It seems like a decent idea to provide the option of rearranging them.

I personally think that doing so via purely config files is fine; doing it through command line sounds incredibly messy.

Additional context/details

Current Status

Provide any additional context or details here. What needs to be done, why, etc:

• This will require redoing how we currently manage widget movement (that's hard coded)

• Planning out how we plan to allow customization - what things will we let users change? What things will we not?

• Configuration files and format

• Getting canvas to accept this layout

• Movement

• Expanded mode

• Default widget option

• Basic mode - how will this play out?

• Cleanup if required (currently, some FIXMEs)

• Testing

Windows temp sensors might not be working?

Describe the bug

Don't seem to be able to get any temp outputs on Windows.

To reproduce

Steps on how to reproduce the behaviour:

1. Go to bottom and look at the temp sensors.
2. They're blank for me

Screenshots

If applicable, add screenshots to help explain your problem.

Platform

Provide information on:

Operating System: Windows

Terminal: Powershell

Any other relevant information (more details are always good!):

Additional context

If anything hasn't been covered by the above categories, state it down here.

This would really be on the temperature providers I'm using. Worst case, I just write the detection myself... yay...

AUR build broken

curl: (22) The requested URL returned error: 404 Not Found
==> ERROR: Failure while downloading https://github.com/ClementTsang/bottom/releases/download/0.2.2/bottom_source_code.tar.gz
    Aborting...
Error downloading sources: bottom

Fix dialog boxes to be a constant width/height if possible, and modify search to not block if the window is small

Describe the bug

A clear and concise description of what the bug is and what the expected behaviour was. If applicable, add screenshots to help explain your problem:

This mainly applies to the dd and ? boxes - setting a constant width/height (or at least height) is probably a good idea.

To reproduce

Steps on how to reproduce the behaviour:

1. Try using dd on a small window.

Platform

If relevant, please provide information on:

Operating System:

Terminal:

Shell:

Any other relevant information (more details are always good!):

Additional context

If anything hasn't been covered by the above categories, state it down here:

What is the different between "bottom_source_code.tar.gz" and "Source code (tar.gz)" on Release Page?

What is the different? Why is bottom_source_code.tar.gz necessary?

release page

Refactor widgets into separate files

Describe the chore

What is it that needs to be done? If relevant, say why:

Currently the canvas file is huge and a pain to work with. If no regressions arise, refactoring this would be good.

CPU colour is incorrect when you hide a cpu

Describe the bug

A clear and concise description of what the bug is and what the expected behaviour was. If applicable, add screenshots to help explain your problem:

They're grabbing the wrong colour - caused by how we determine colour in the CPU legend drawing.

To reproduce

Steps on how to reproduce the behaviour:

1. Observe colour of a core
2. Hide the core
3. Observe colour of the next CPU core

Platform

If relevant, please provide information on:

Operating System:

Terminal:

Shell:

Any other relevant information (more details are always good!):

Additional context

If anything hasn't been covered by the above categories, state it down here:

Hidden cpus can still be scrolled

Describe the bug

A clear and concise description of what the bug is and what the expected behaviour was. If applicable, add screenshots to help explain your problem:

When you hide a CPU, you can still scroll to it on the list.

To reproduce

Steps on how to reproduce the behaviour:

1. Hide all but 1 cpu (any amount works but this illustrates it)
2. Scroll

Platform

If relevant, please provide information on:

Operating System:

Terminal:

Shell:

Any other relevant information (more details are always good!):

Additional context

If anything hasn't been covered by the above categories, state it down here:

Basic mode

Describe the feature request

Emulate almost a htop level of interface in this mode. No graphs. Be simple.

Additional context

Provide any additional context here.

Will need some sketchups of how to do this. Should not be too hard. Hopefully.

• Design
• Add canvas implementation
• Add config + flag
• Add widget movement specifically for this mode
• Test
• Fix search bar overall
• Add table switching
• Add config default positions working on table switching in basic mode
• Documentation - need to add in help, README
• Prompt for table switching? Might be hard to remember which one is next, for example.

Bug: Cannot divide by 0

bottom/src/convert_data.rs

Lines 187 to 190 in e00b2bd

	let new_entry = (
	((STALE_MAX_MILLISECONDS as f64 - current_time.duration_since(data.instant).as_millis() as f64) * 10_f64).floor(),
	data.mem_used_in_mb as f64 / data.mem_total_in_mb as f64 * 100_f64,
	);

data.mem_total_in_mb :
Sometimes it is 0, So the result is NaN.

bottom/src/main.rs

Lines 197 to 200 in e00b2bd

	canvas_data.process_data = update_process_row(&app.data);
	canvas_data.mem_data = update_mem_data_points(&app.data);
	canvas_data.swap_data = update_swap_data_points(&app.data);
	canvas_data.cpu_data = update_cpu_data_points(app.show_average_cpu, &app.data);

Calling update_swap_data_points in Event::Update will cause the program to quit

Add customization to network range in Y-axis

Describe the feature request

Why should we consider this feature request? Describe why, and/or how you think this feature will solve the issue, or overall improve the application:

For things like CPU% or mem%, it's easy to range from 0 - 100.

It's a bit harder for networking - maybe someone is using 1Gbit+ on the regular. Or maybe they'll never hit it and are more concerned with lower levels. Furthermore, then maybe the whole logarithmic scale of networking isn't needed!

Adding custom ranges, the ability to use log scale or not, and maybe even automatic changing of the Y-scale (toggleable) would be a good idea.

Additional context/details

Provide any additional context or details here. What needs to be done, why, etc:

• Config option to set what points to track on Y-axis of network Not doing this for now
• Ability to disable or enable log scaling
• Automatic scaling... maybe?

May be make search case insensitive?

When searching for processes in the search widget (called by either / or <C-f>), may be make this search case insensitive?

(Otherwise, everything seems to be working fine on macOS.)

Some chars (likely unicode) crash search

Describe the bug

A clear and concise description of what the bug is and what the expected behaviour was:

Typing Option+C then another character crashes the program.

To reproduce

Steps on how to reproduce the behaviour:

1. Open search
2. Type Option + C
3. Type another character

Screenshots

If applicable, add screenshots to help explain your problem:

Platform

Provide information on:

Operating System: macOS

Terminal: Kitty

Any other relevant information (more details are always good!):

Additional context

If anything hasn't been covered by the above categories, state it down here:

Trace:

stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /Users/ctsang/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.43/src/backtrace/libunwind.rs:86
      backtrace::backtrace::trace_unsynchronized
             at /Users/ctsang/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.43/src/backtrace/mod.rs:66
   1: backtrace::backtrace::trace
             at /Users/ctsang/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.43/src/backtrace/mod.rs:53
   2: backtrace::capture::Backtrace::create
             at /Users/ctsang/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.43/src/capture.rs:164
   3: backtrace::capture::Backtrace::new
             at /Users/ctsang/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.43/src/capture.rs:128
   4: btm::panic_hook
             at src/main.rs:772
   5: btm::main::{{closure}}
             at src/main.rs:186
   6: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:468
   7: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:373
   8: rust_begin_unwind
             at src/libstd/panicking.rs:302
   9: std::panicking::begin_panic
  10: std::panicking::begin_panic
  11: alloc::string::String::insert
             at <::core::macros::panic macros>:5
  12: btm::app::App::on_char_key
             at src/app.rs:809
  13: btm::handle_key_event_or_break
             at src/main.rs:331
  14: btm::main
             at src/main.rs:225
  15: std::rt::lang_start::{{closure}}
             at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/rt.rs:61
  16: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:48
      std::panicking::try::do_call
             at src/libstd/panicking.rs:287
  17: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:78
  18: std::panicking::try
             at src/libstd/panicking.rs:265
      std::panic::catch_unwind
             at src/libstd/panic.rs:396
      std::rt::lang_start_internal
             at src/libstd/rt.rs:47
  19: std::rt::lang_start
             at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/rt.rs:61
  20: <btm::_IMPL_DESERIALIZE_FOR_ConfigColours::<impl serde::de::Deserialize for btm::ConfigColours>::deserialize::__Visitor as serde::de::Visitor>::expecting

Revisit maximizing to make it more useful, put in more info

Describe the feature request

Maximizing is currently fine in that it literally just does that - maximize.

Now, time to take a look at part 2 - adding more details if possible. Stuff that can't fit on the normal size.

Additional context

We can also (I guess) use this to extend some other widgets. Or at least try (I guess this is gonna push back the release pretty hard but oh well, might as well do it now).

I guess a general good idea is to see what stuff like top has, and see if we can also display similar data. Whether all of these will be available cross-platform is another story.

...also I might rebind the maximize key to M or even m. Just gonna put that out there. Enter is too useful of a key and makes sense for other tasks IMO.

Possible candidates:

CPU

Overall I think I might switch to heim purely for functionality reasons first, then go about implementing extra details. I wouldn't graph most of these but just display them, maybe a Paragraph widget or something.

• Frequency (heim and sysinfo both support this)
• CTX-switch and interrupts (heim)
• Software-interrupts (linux only, heim)
• Load average (sysinfo handles this, not sure if heim does. But if we want to switch to heim...)
• Apparently someone is interested in CPI. I guess this is doable... maybe? I don't know.
• At least for linux, heim does support all cpu times. I can display this (per cpu + avg) if that's desirable.
  • Perhaps those cpu times... per second (like delta / s). I don't know.
• Someone also seems interested in scheduler latency. I don't... really know how easy that will be to do on Linux, let alone cross-platform. It seems we can do something along the lines of this calculation for Linux?

RAM

• Could be interesting to display stuff like page faults? The main problem is that neither heim nor sysinfo support this - and this might end up being a Linux-specific implementation for a while (macOS and Windows are ??? for me as of writing this). Which I kinda hate. It's definitely doable though... I think.
• buff/cache values. heim.

Processes

Some of these might just become columns overall but given a later priority in terms of drawing.

Also something unrelated is allowing disabling certain columns (some people probably won't care about this (and other extra columns)).

• Give an easy count to how many tasks, task state (sleep/zombie/running/stopped)
• Add process state.
• Showing actual values of mem usage?
• Virtual memory?
• I/O stats a la #58 (though that might just go there in general). Doing this will close that task too.

Network

• #52 might be a good fit here. The smaller minimized version might be too chaotic with a small space right now (though that might change in the future if I can get rid of the table legend, and that's also a bit of a lie when you look at CPU graphs tbh). Doing this will close that task.
• NIC data (see heim)
• May want to increase network to 10GB/s overall, or at least here.

Temps

• As mentioned, graph this data. Scale it to... I think 100 degrees is fine? Maybe set it to like -10 to 110 C (dunno how many people would need subzero let's be real)

Disks

• As mentioned, graph IO/s. Probably range logarithmically from 0B/s to like... 10GB/s? Maybe a bit higher? Any more seems like overkill quite frankly. Maybe 1TB/s?