6 files changed, 47 insertions, 28 deletions

diff --git a/nightly/configuration/command-line-flags/index.html b/nightly/configuration/command-line-flags/index.html
index c8305f35..1fd356ec 100644
--- a/nightly/configuration/command-line-flags/index.html
+++ b/nightly/configuration/command-line-flags/index.html
@@ -1150,6 +1150,10 @@
 <td><code>-W, --whole_word</code></td>
 <td>Enables whole-word matching by default.</td>
 </tr>
+<tr>
+<td><code>--enable_gpu_memory</code></td>
+<td>Enable collecting and displaying GPU memory usage.</td>
+</tr>
 </tbody>
 </table>
 
diff --git a/nightly/configuration/config-file/flags/index.html b/nightly/configuration/config-file/flags/index.html
index 174d6fce..1d89d733 100644
--- a/nightly/configuration/config-file/flags/index.html
+++ b/nightly/configuration/config-file/flags/index.html
@@ -1153,6 +1153,11 @@
 <td>Boolean</td>
 <td>Displays the network widget with a log scale.</td>
 </tr>
+<tr>
+<td><code>enable_gpu_memory</code></td>
+<td>Boolean</td>
+<td>Shows the GPU memory widget.</td>
+</tr>
 </tbody>
 </table>
 
diff --git a/nightly/configuration/config-file/theming/index.html b/nightly/configuration/config-file/theming/index.html
index 7e99f439..86deb342 100644
--- a/nightly/configuration/config-file/theming/index.html
+++ b/nightly/configuration/config-file/theming/index.html
@@ -1109,6 +1109,16 @@
 <td>The colour used for a low battery level (10% to 0%)</td>
 <td><code>low_battery_color="red"</code></td>
 </tr>
+<tr>
+<td>GPU colour per gpu</td>
+<td>Colour of each gpu. Read in order.</td>
+<td><code>gpu_core_colors=["#ffffff", "white", "255, 255, 255"]</code></td>
+</tr>
+<tr>
+<td>ARC</td>
+<td>The colour ARC will use</td>
+<td><code>arc_color="#ffffff"</code></td>
+</tr>
 </tbody>
 </table>
 
diff --git a/nightly/search/search_index.json b/nightly/search/search_index.json
index 366e98e8..8c31f9b9 100644
--- a/nightly/search/search_index.json
+++ b/nightly/search/search_index.json
@@ -1 +1 @@
-{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"bottom This site serves as extended documentation for bottom alongside the README.md . Warning Some areas of this site are still in progress and may be missing details. Feel free to suggest/contribute changes! Installation Tip It is a good idea to first check out the Support page to see if your system is officially supported! Tip If you're facing some issues during/after installation, check out the Troubleshooting page for some common problems and solutions. To install bottom, refer to the installation section of the README.md , which contains a list of all the installation methods. Contribution New contributors are always welcome! See the contribution section for how to contribute to bottom, whether it be filing issues, writing documentation, creating pull requests, etc.","title":"Home"},{"location":"#bottom","text":"This site serves as extended documentation for bottom alongside the README.md . Warning Some areas of this site are still in progress and may be missing details. Feel free to suggest/contribute changes!","title":"bottom"},{"location":"#installation","text":"Tip It is a good idea to first check out the Support page to see if your system is officially supported! Tip If you're facing some issues during/after installation, check out the Troubleshooting page for some common problems and solutions. To install bottom, refer to the installation section of the README.md , which contains a list of all the installation methods.","title":"Installation"},{"location":"#contribution","text":"New contributors are always welcome! See the contribution section for how to contribute to bottom, whether it be filing issues, writing documentation, creating pull requests, etc.","title":"Contribution"},{"location":"troubleshooting/","text":"Troubleshooting The graph points look broken/strange It's possible that your graphs won't look great out of the box due to the reliance on braille fonts to draw them. One example of this is seeing a bunch of missing font characters, caused when the terminal isn't configured properly to render braille fonts. Powershell shown missing braille fonts One alternative is to use the --dot_marker option to render graph charts using dots instead of the braille characters, which generally seems better supported out of the box, at the expense of looking less intricate: Example using btm --dot_marker Another (better) alternative is to install a font that supports braille fonts, and configure your terminal to use it. For example, installing something like UBraille or Iosevka and ensuring your terminal uses it should work. Installing fonts for Windows Command Prompt/PowerShell Note: I would advise backing up your registry beforehand if you aren't sure what you are doing! Let's say you're installing Iosevka . The steps you can take are: Install the font itself. Open the registry editor, which you can do either by Win+R and opening regedit , or just opening it from the Start Menu. In the registry editor, go to HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Console\\TrueTypeFont Here, add a new String value , and set the Name to a bunch of 0's (e.g. 000 - make sure the name isn't already used), then set the Data to the font name (e.g. Iosevka ). The last entry is the new entry for Iosevka Then, open the Command Prompt/PowerShell, and right click on the top bar, and open Properties : From here, go to Font , and set the font to your new font (e.g. Iosevka ): Why can't I see all my temperature sensors on Windows? This is a known limitation , some sensors may require admin privileges to get sensor data. Why don't I see dual batteries on Windows reported separately? (e.g. Thinkpads) This is a known limitation which seems to be with how batteries are being detected on Windows. Why can't I see all my temperature sensors on WSL? This is a known limitation with WSL. Due to how it works, hosts may not expose their temperature sensors and therefore, temperature sensors might be missing. Why does WSL2 not match Task Manager? This is a known limitation with WSL2. Due to how WSL2 works, the two might not match up in terms of reported data. Why can't I see all my processes/process data on macOS? This is a known limitation , and you may have to run the program with elevated privileges to work around it - for example: sudo btm Please note that you should be certain that you trust any software you grant root privileges. There are measures taken to try to maximize the amount of information obtained without elevated privileges. For example, one can modify the instructions found on the htop wiki on how to run htop without sudo for bottom. However please understand the potential security risks before doing so! My configuration file isn't working If your configuration files aren't working, here are a few things to try: Check the formatting It may be handy to refer to the automatically generated config files or the sample configuration files . The config files also follow the TOML format. Also make sure your config options are under the right table - for example, to set your temperature type, you must set it under the [flags] table: [flags] temperature_type = \"f\" Meanwhile, if you want to set a custom color scheme, it would be under the [colors] table: [colors] table_header_color = \"LightBlue\" Check the configuration file location Make sure bottom is reading the right configuration file. By default, bottom looks for config files at these locations: OS Default Config Location macOS $HOME/Library/Application Support/bottom/bottom.toml ~/.config/bottom/bottom.toml $XDG_CONFIG_HOME/bottom/bottom.toml Linux ~/.config/bottom/bottom.toml $XDG_CONFIG_HOME/bottom/bottom.toml Windows C:\\Users\\<USER>\\AppData\\Roaming\\bottom\\bottom.toml If you want to use a config file in another location, use the --config or -C flags along with the path to the configuration file, like so: btm -C path_to_config My installation through snap has some widgets that are blank/show no data Make sure bottom is given the correct permissions in order to collect data. Snapcraft explains how to do so, but the TL;DR is: sudo snap connect bottom:mount-observe sudo snap connect bottom:hardware-observe sudo snap connect bottom:system-observe sudo snap connect bottom:process-control","title":"Troubleshooting"},{"location":"troubleshooting/#troubleshooting","text":"","title":"Troubleshooting"},{"location":"troubleshooting/#the-graph-points-look-brokenstrange","text":"It's possible that your graphs won't look great out of the box due to the reliance on braille fonts to draw them. One example of this is seeing a bunch of missing font characters, caused when the terminal isn't configured properly to render braille fonts. Powershell shown missing braille fonts One alternative is to use the --dot_marker option to render graph charts using dots instead of the braille characters, which generally seems better supported out of the box, at the expense of looking less intricate: Example using btm --dot_marker Another (better) alternative is to install a font that supports braille fonts, and configure your terminal to use it. For example, installing something like UBraille or Iosevka and ensuring your terminal uses it should work.","title":"The graph points look broken/strange"},{"location":"troubleshooting/#installing-fonts-for-windows-command-promptpowershell","text":"Note: I would advise backing up your registry beforehand if you aren't sure what you are doing! Let's say you're installing Iosevka . The steps you can take are: Install the font itself. Open the registry editor, which you can do either by Win+R and opening regedit , or just opening it from the Start Menu. In the registry editor, go to HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Console\\TrueTypeFont Here, add a new String value , and set the Name to a bunch of 0's (e.g. 000 - make sure the name isn't already used), then set the Data to the font name (e.g. Iosevka ). The last entry is the new entry for Iosevka Then, open the Command Prompt/PowerShell, and right click on the top bar, and open Properties : From here, go to Font , and set the font to your new font (e.g. Iosevka ):","title":"Installing fonts for Windows Command Prompt/PowerShell"},{"location":"troubleshooting/#why-cant-i-see-all-my-temperature-sensors-on-windows","text":"This is a known limitation , some sensors may require admin privileges to get sensor data.","title":"Why can't I see all my temperature sensors on Windows?"},{"location":"troubleshooting/#why-dont-i-see-dual-batteries-on-windows-reported-separately-eg-thinkpads","text":"This is a known limitation which seems to be with how batteries are being detected on Windows.","title":"Why don't I see dual batteries on Windows reported separately? (e.g. Thinkpads)"},{"location":"troubleshooting/#why-cant-i-see-all-my-temperature-sensors-on-wsl","text":"This is a known limitation with WSL. Due to how it works, hosts may not expose their temperature sensors and therefore, temperature sensors might be missing.","title":"Why can't I see all my temperature sensors on WSL?"},{"location":"troubleshooting/#why-does-wsl2-not-match-task-manager","text":"This is a known limitation with WSL2. Due to how WSL2 works, the two might not match up in terms of reported data.","title":"Why does WSL2 not match Task Manager?"},{"location":"troubleshooting/#why-cant-i-see-all-my-processesprocess-data-on-macos","text":"This is a known limitation , and you may have to run the program with elevated privileges to work around it - for example: sudo btm Please note that you should be certain that you trust any software you grant root privileges. There are measures taken to try to maximize the amount of information obtained without elevated privileges. For example, one can modify the instructions found on the htop wiki on how to run htop without sudo for bottom. However please understand the potential security risks before doing so!","title":"Why can't I see all my processes/process data on macOS?"},{"location":"troubleshooting/#my-configuration-file-isnt-working","text":"If your configuration files aren't working, here are a few things to try:","title":"My configuration file isn't working"},{"location":"troubleshooting/#check-the-formatting","text":"It may be handy to refer to the automatically generated config files or the sample configuration files . The config files also follow the TOML format. Also make sure your config options are under the right table - for example, to set your temperature type, you must set it under the [flags] table: [flags] temperature_type = \"f\" Meanwhile, if you want to set a custom color scheme, it would be under the [colors] table: [colors] table_header_color = \"LightBlue\"","title":"Check the formatting"},{"location":"troubleshooting/#check-the-configuration-file-location","text":"Make sure bottom is reading the right configuration file. By default, bottom looks for config files at these locations: OS Default Config Location macOS $HOME/Library/Application Support/bottom/bottom.toml ~/.config/bottom/bottom.toml $XDG_CONFIG_HOME/bottom/bottom.toml Linux ~/.config/bottom/bottom.toml $XDG_CONFIG_HOME/bottom/bottom.toml Windows C:\\Users\\<USER>\\AppData\\Roaming\\bottom\\bottom.toml If you want to use a config file in another location, use the --config or -C flags along with the path to the configuration file, like so: btm -C path_to_config","title":"Check the configuration file location"},{"location":"troubleshooting/#my-installation-through-snap-has-some-widgets-that-are-blankshow-no-data","text":"Make sure bottom is given the correct permissions in order to collect data. Snapcraft explains how to do so, but the TL;DR is: sudo snap connect bottom:mount-observe sudo snap connect bottom:hardware-observe sudo snap connect bottom:system-observe sudo snap connect bottom:process-control","title":"My installation through snap has some widgets that are blank/show no data"},{"location":"configuration/command-line-flags/","text":"Command-line Flags Warning This section is in progress, and is just copied from the old documentation. The following flags can be provided to bottom in the command line to change the behaviour of the program (run btm --help for more information on each flag): Flag Behaviour --autohide_time Temporarily shows the time scale in graphs. -b, --basic Hides graphs and uses a more basic look. --battery Shows the battery widget. -S, --case_sensitive Enables case sensitivity by default. -c, --celsius Sets the temperature type to Celsius. --color <COLOR SCHEME> Use a color scheme, use --help for supported values. -C, --config <CONFIG PATH> Sets the location of the config file. -u, --current_usage Sets process CPU% to be based on current CPU%. -t, --default_time_value <MS> Default time value for graphs in ms. --default_widget_count <INT> Sets the n'th selected widget type as the default. --default_widget_type <WIDGET TYPE> Sets the default widget type, use --help for more info. --disable_advanced_kill Hides advanced options to stop a process on Unix-like systems. --disable_click Disables mouse clicks. -m, --dot_marker Uses a dot marker for graphs. -f, --fahrenheit Sets the temperature type to Fahrenheit. -g, --group Groups processes with the same name by default. -h, --help Prints help information. Use --help for more info. -a, --hide_avg_cpu Hides the average CPU usage. --hide_table_gap Hides the spacing between table headers and entries. --hide_time Hides the time scale. -k, --kelvin Sets the temperature type to Kelvin. -l, --left_legend Puts the CPU chart legend to the left side. --mem_as_value Defaults to showing process memory usage by value. --network_use_binary_prefix Displays the network widget with binary prefixes. --network_use_bytes Displays the network widget using bytes. --network_use_log Displays the network widget with a log scale. --process_command Show processes as their commands by default. -r, --rate <MS> Sets a refresh rate in ms. -R, --regex Enables regex by default. --show_table_scroll_position Shows the scroll position tracker in table widgets. -d, --time_delta <MS> The amount in ms changed upon zooming. -T, --tree Defaults to showing the process widget in tree mode. --use_old_network_legend DEPRECATED - uses the older network legend. -V, --version Prints version information. -W, --whole_word Enables whole-word matching by default.","title":"Command-line Flags"},{"location":"configuration/command-line-flags/#command-line-flags","text":"Warning This section is in progress, and is just copied from the old documentation. The following flags can be provided to bottom in the command line to change the behaviour of the program (run btm --help for more information on each flag): Flag Behaviour --autohide_time Temporarily shows the time scale in graphs. -b, --basic Hides graphs and uses a more basic look. --battery Shows the battery widget. -S, --case_sensitive Enables case sensitivity by default. -c, --celsius Sets the temperature type to Celsius. --color <COLOR SCHEME> Use a color scheme, use --help for supported values. -C, --config <CONFIG PATH> Sets the location of the config file. -u, --current_usage Sets process CPU% to be based on current CPU%. -t, --default_time_value <MS> Default time value for graphs in ms. --default_widget_count <INT> Sets the n'th selected widget type as the default. --default_widget_type <WIDGET TYPE> Sets the default widget type, use --help for more info. --disable_advanced_kill Hides advanced options to stop a process on Unix-like systems. --disable_click Disables mouse clicks. -m, --dot_marker Uses a dot marker for graphs. -f, --fahrenheit Sets the temperature type to Fahrenheit. -g, --group Groups processes with the same name by default. -h, --help Prints help information. Use --help for more info. -a, --hide_avg_cpu Hides the average CPU usage. --hide_table_gap Hides the spacing between table headers and entries. --hide_time Hides the time scale. -k, --kelvin Sets the temperature type to Kelvin. -l, --left_legend Puts the CPU chart legend to the left side. --mem_as_value Defaults to showing process memory usage by value. --network_use_binary_prefix Displays the network widget with binary prefixes. --network_use_bytes Displays the network widget using bytes. --network_use_log Displays the network widget with a log scale. --process_command Show processes as their commands by default. -r, --rate <MS> Sets a refresh rate in ms. -R, --regex Enables regex by default. --show_table_scroll_position Shows the scroll position tracker in table widgets. -d, --time_delta <MS> The amount in ms changed upon zooming. -T, --tree Defaults to showing the process widget in tree mode. --use_old_network_legend DEPRECATED - uses the older network legend. -V, --version Prints version information. -W, --whole_word Enables whole-word matching by default.","title":"Command-line Flags"},{"location":"configuration/config-file/data-filtering/","text":"Data Filtering Warning This section is in progress, and is just copied from the old documentation. You can hide specific disks, temperature sensors, and networks by name in the config file via disk_filter and mount_filter , temp_filter , and net_filter respectively. Regex ( regex = true ), case-sensitivity ( case_sensitive = true ), and matching only if the entire word matches ( whole_word = true ) are supported, but are off by default. Filters default to denying entries that match and can be toggled by setting is_list_ignored to false in the config file. For example, here's the disk widget with no filter: The following in the config file would filter out some entries by disk name: [disk_filter] is_list_ignored = true list = [ \"/dev/sda\" ] regex = true case_sensitive = false whole_word = false If there are two potentially conflicting filters (i.e. when you are using both a disk and mount filter), the filter that explicitly allows an entry takes precedence over a filter that explicitly denies one. So for example, let's say we set a disk filter accepting anything with /dev/sda , but deny anything with /mnt/.* or / . So to do so, we write in the config file: [disk_filter] is_list_ignored = false list = [ \"/dev/sda\" ] regex = true case_sensitive = false whole_word = false [mount_filter] is_list_ignored = true list = [ \"/mnt/.*\" , \"/\" ] regex = true case_sensitive = false whole_word = true This gives us:","title":"Data Filtering"},{"location":"configuration/config-file/data-filtering/#data-filtering","text":"Warning This section is in progress, and is just copied from the old documentation. You can hide specific disks, temperature sensors, and networks by name in the config file via disk_filter and mount_filter , temp_filter , and net_filter respectively. Regex ( regex = true ), case-sensitivity ( case_sensitive = true ), and matching only if the entire word matches ( whole_word = true ) are supported, but are off by default. Filters default to denying entries that match and can be toggled by setting is_list_ignored to false in the config file. For example, here's the disk widget with no filter: The following in the config file would filter out some entries by disk name: [disk_filter] is_list_ignored = true list = [ \"/dev/sda\" ] regex = true case_sensitive = false whole_word = false If there are two potentially conflicting filters (i.e. when you are using both a disk and mount filter), the filter that explicitly allows an entry takes precedence over a filter that explicitly denies one. So for example, let's say we set a disk filter accepting anything with /dev/sda , but deny anything with /mnt/.* or / . So to do so, we write in the config file: [disk_filter] is_list_ignored = false list = [ \"/dev/sda\" ] regex = true case_sensitive = false whole_word = false [mount_filter] is_list_ignored = true list = [ \"/mnt/.*\" , \"/\" ] regex = true case_sensitive = false whole_word = true This gives us:","title":"Data Filtering"},{"location":"configuration/config-file/default-config/","text":"Default Config A default config file is automatically generated at the following locations that bottom checks by default: OS Default Config Location macOS $HOME/Library/Application Support/bottom/bottom.toml ~/.config/bottom/bottom.toml $XDG_CONFIG_HOME/bottom/bottom.toml Linux ~/.config/bottom/bottom.toml $XDG_CONFIG_HOME/bottom/bottom.toml Windows C:\\Users\\<USER>\\AppData\\Roaming\\bottom\\bottom.toml Furthermore, if a custom config path that does not exist is given (using -C or --config ), bottom will attempt to create a default config file at that location.","title":"Default Config"},{"location":"configuration/config-file/default-config/#default-config","text":"A default config file is automatically generated at the following locations that bottom checks by default: OS Default Config Location macOS $HOME/Library/Application Support/bottom/bottom.toml ~/.config/bottom/bottom.toml $XDG_CONFIG_HOME/bottom/bottom.toml Linux ~/.config/bottom/bottom.toml $XDG_CONFIG_HOME/bottom/bottom.toml Windows C:\\Users\\<USER>\\AppData\\Roaming\\bottom\\bottom.toml Furthermore, if a custom config path that does not exist is given (using -C or --config ), bottom will attempt to create a default config file at that location.","title":"Default Config"},{"location":"configuration/config-file/flags/","text":"Flags Warning This section is in progress, and is just copied from the old documentation. Most of the command line flags have config file equivalents to avoid having to type them out each time: Field Type Functionality hide_avg_cpu Boolean Hides the average CPU usage. dot_marker Boolean Uses a dot marker for graphs. left_legend Boolean Puts the CPU chart legend to the left side. current_usage Boolean Sets process CPU% to be based on current CPU%. group_processes Boolean Groups processes with the same name by default. case_sensitive Boolean Enables case sensitivity by default. whole_word Boolean Enables whole-word matching by default. regex Boolean Enables regex by default. basic Boolean Hides graphs and uses a more basic look. use_old_network_legend Boolean DEPRECATED - uses the older network legend. battery Boolean Shows the battery widget. rate Unsigned Int (represents milliseconds) Sets a refresh rate in ms. default_time_value Unsigned Int (represents milliseconds) Default time value for graphs in ms. time_delta Unsigned Int (represents milliseconds) The amount in ms changed upon zooming. hide_time Boolean Hides the time scale. temperature_type String (one of [\"k\", \"f\", \"c\", \"kelvin\", \"fahrenheit\", \"celsius\"]) Sets the temperature unit type. default_widget_type String (one of [\"cpu\", \"proc\", \"net\", \"temp\", \"mem\", \"disk\"], same as layout options) Sets the default widget type, use --help for more info. default_widget_count Unsigned Int (represents which default_widget_type ) Sets the n'th selected widget type as the default. disable_click Boolean Disables mouse clicks. color String (one of [\"default\", \"default-light\", \"gruvbox\", \"gruvbox-light\", \"nord\", \"nord-light\"]) Use a color scheme, use --help for supported values. mem_as_value Boolean Defaults to showing process memory usage by value. tree Boolean Defaults to showing the process widget in tree mode. show_table_scroll_position Boolean Shows the scroll position tracker in table widgets. process_command Boolean Show processes as their commands by default. disable_advanced_kill Boolean Hides advanced options to stop a process on Unix-like systems. network_use_binary_prefix Boolean Displays the network widget with binary prefixes. network_use_bytes Boolean Displays the network widget using bytes. network_use_log Boolean Displays the network widget with a log scale.","title":"Flags"},{"location":"configuration/config-file/flags/#flags","text":"Warning This section is in progress, and is just copied from the old documentation. Most of the command line flags have config file equivalents to avoid having to type them out each time: Field Type Functionality hide_avg_cpu Boolean Hides the average CPU usage. dot_marker Boolean Uses a dot marker for graphs. left_legend Boolean Puts the CPU chart legend to the left side. current_usage Boolean Sets process CPU% to be based on current CPU%. group_processes Boolean Groups processes with the same name by default. case_sensitive Boolean Enables case sensitivity by default. whole_word Boolean Enables whole-word matching by default. regex Boolean Enables regex by default. basic Boolean Hides graphs and uses a more basic look. use_old_network_legend Boolean DEPRECATED - uses the older network legend. battery Boolean Shows the battery widget. rate Unsigned Int (represents milliseconds) Sets a refresh rate in ms. default_time_value Unsigned Int (represents milliseconds) Default time value for graphs in ms. time_delta Unsigned Int (represents milliseconds) The amount in ms changed upon zooming. hide_time Boolean Hides the time scale. temperature_type String (one of [\"k\", \"f\", \"c\", \"kelvin\", \"fahrenheit\", \"celsius\"]) Sets the temperature unit type. default_widget_type String (one of [\"cpu\", \"proc\", \"net\", \"temp\", \"mem\", \"disk\"], same as layout options) Sets the default widget type, use --help for more info. default_widget_count Unsigned Int (represents which default_widget_type ) Sets the n'th selected widget type as the default. disable_click Boolean Disables mouse clicks. color String (one of [\"default\", \"default-light\", \"gruvbox\", \"gruvbox-light\", \"nord\", \"nord-light\"]) Use a color scheme, use --help for supported values. mem_as_value Boolean Defaults to showing process memory usage by value. tree Boolean Defaults to showing the process widget in tree mode. show_table_scroll_position Boolean Shows the scroll position tracker in table widgets. process_command Boolean Show processes as their commands by default. disable_advanced_kill Boolean Hides advanced options to stop a process on Unix-like systems. network_use_binary_prefix Boolean Displays the network widget with binary prefixes. network_use_bytes Boolean Displays the network widget using bytes. network_use_log Boolean Displays the network widget with a log scale.","title":"Flags"},{"location":"configuration/config-file/layout/","text":"Layout Warning This section is in progress, and is just copied from the old documentation. bottom supports customizable layouts via the config file. Currently, layouts are controlled by using TOML objects and arrays. For example, given the sample layout: [[row]] [[row.child]] type = \"cpu\" [[row]] ratio = 2 [[row.child]] ratio = 4 type = \"mem\" [[row.child]] ratio = 3 [[row.child.child]] type = \"temp\" [[row.child.child]] type = \"disk\" This would give a layout that has two rows, with a 1:2 ratio. The first row has only the CPU widget. The second row is split into two columns with a 4:3 ratio. The first column contains the memory widget. The second column is split into two rows with a 1:1 ratio. The first is the temperature widget, the second is the disk widget. This is what the layout would look like when run: Each [[row]] represents a row in the layout. A row can have any number of child values. Each [[row.child]] represents either a column or a widget . A column can have any number of child values as well. Each [[row.child.child]] represents a widget . A widget is represented by having a type field set to a string. The following type values are supported: \"cpu\" CPU chart and legend \"mem\", \"memory\" Memory chart \"net\", \"network\" Network chart and legend \"proc\", \"process\", \"processes\" Process table and search \"temp\", \"temperature\" Temperature table \"disk\" Disk table \"empty\" An empty space \"batt\", \"battery\" Battery statistics Each component of the layout accepts a ratio value. If this is not set, it defaults to 1. Furthermore, you can have duplicate widgets. For an example, look at the default config , which contains the default layout.","title":"Layout"},{"location":"configuration/config-file/layout/#layout","text":"Warning This section is in progress, and is just copied from the old documentation. bottom supports customizable layouts via the config file. Currently, layouts are controlled by using TOML objects and arrays. For example, given the sample layout: [[row]] [[row.child]] type = \"cpu\" [[row]] ratio = 2 [[row.child]] ratio = 4 type = \"mem\" [[row.child]] ratio = 3 [[row.child.child]] type = \"temp\" [[row.child.child]] type = \"disk\" This would give a layout that has two rows, with a 1:2 ratio. The first row has only the CPU widget. The second row is split into two columns with a 4:3 ratio. The first column contains the memory widget. The second column is split into two rows with a 1:1 ratio. The first is the temperature widget, the second is the disk widget. This is what the layout would look like when run: Each [[row]] represents a row in the layout. A row can have any number of child values. Each [[row.child]] represents either a column or a widget . A column can have any number of child values as well. Each [[row.child.child]] represents a widget . A widget is represented by having a type field set to a string. The following type values are supported: \"cpu\" CPU chart and legend \"mem\", \"memory\" Memory chart \"net\", \"network\" Network chart and legend \"proc\", \"process\", \"processes\" Process table and search \"temp\", \"temperature\" Temperature table \"disk\" Disk table \"empty\" An empty space \"batt\", \"battery\" Battery statistics Each component of the layout accepts a ratio value. If this is not set, it defaults to 1. Furthermore, you can have duplicate widgets. For an example, look at the default config , which contains the default layout.","title":"Layout"},{"location":"configuration/config-file/theming/","text":"Theming Warning This section is in progress, and is just copied from the old documentation. The config file can be used to set custom colours for parts of the application under the [colors] object. The following labels are customizable with strings that are hex colours, RGB colours, or specific named colours. Supported named colours are one of the following strings: Reset, Black, Red, Green, Yellow, Blue, Magenta, Cyan, Gray, DarkGray, LightRed, LightGreen, LightYellow, LightBlue, LightMagenta, LightCyan, White . Labels Details Example Table header colours Colour of table headers table_header_color=\"255, 255, 255\" CPU colour per core Colour of each core. Read in order. cpu_core_colors=[\"#ffffff\", \"white\", \"255, 255, 255\"] Average CPU colour The average CPU color avg_cpu_color=\"White\" All CPUs colour The colour for the \"All\" CPU label all_cpu_color=\"White\" RAM The colour RAM will use ram_color=\"#ffffff\" SWAP The colour SWAP will use swap_color=\"#ffffff\" RX The colour rx will use rx_color=\"#ffffff\" TX The colour tx will use tx_color=\"#ffffff\" Widget title colour The colour of the label each widget has widget_title_color=\"#ffffff\" Border colour The colour of the border of unselected widgets border_color=\"#ffffff\" Selected border colour The colour of the border of selected widgets highlighted_border_color=\"#ffffff\" Text colour The colour of most text text_color=\"#ffffff\" Graph colour The colour of the lines and text of the graph graph_color=\"#ffffff\" Cursor colour The cursor's colour cursor_color=\"#ffffff\" Selected text colour The colour of text that is selected scroll_entry_text_color=\"#ffffff\" Selected text background colour The background colour of text that is selected scroll_entry_bg_color=\"#ffffff\" High battery level colour The colour used for a high battery level (100% to 50%) high_battery_color=\"green\" Medium battery level colour The colour used for a medium battery level (50% to 10%) medium_battery_color=\"yellow\" Low battery level colour The colour used for a low battery level (10% to 0%) low_battery_color=\"red\"","title":"Theming"},{"location":"configuration/config-file/theming/#theming","text":"Warning This section is in progress, and is just copied from the old documentation. The config file can be used to set custom colours for parts of the application under the [colors] object. The following labels are customizable with strings that are hex colours, RGB colours, or specific named colours. Supported named colours are one of the following strings: Reset, Black, Red, Green, Yellow, Blue, Magenta, Cyan, Gray, DarkGray, LightRed, LightGreen, LightYellow, LightBlue, LightMagenta, LightCyan, White . Labels Details Example Table header colours Colour of table headers table_header_color=\"255, 255, 255\" CPU colour per core Colour of each core. Read in order. cpu_core_colors=[\"#ffffff\", \"white\", \"255, 255, 255\"] Average CPU colour The average CPU color avg_cpu_color=\"White\" All CPUs colour The colour for the \"All\" CPU label all_cpu_color=\"White\" RAM The colour RAM will use ram_color=\"#ffffff\" SWAP The colour SWAP will use swap_color=\"#ffffff\" RX The colour rx will use rx_color=\"#ffffff\" TX The colour tx will use tx_color=\"#ffffff\" Widget title colour The colour of the label each widget has widget_title_color=\"#ffffff\" Border colour The colour of the border of unselected widgets border_color=\"#ffffff\" Selected border colour The colour of the border of selected widgets highlighted_border_color=\"#ffffff\" Text colour The colour of most text text_color=\"#ffffff\" Graph colour The colour of the lines and text of the graph graph_color=\"#ffffff\" Cursor colour The cursor's colour cursor_color=\"#ffffff\" Selected text colour The colour of text that is selected scroll_entry_text_color=\"#ffffff\" Selected text background colour The background colour of text that is selected scroll_entry_bg_color=\"#ffffff\" High battery level colour The colour used for a high battery level (100% to 50%) high_battery_color=\"green\" Medium battery level colour The colour used for a medium battery level (50% to 10%) medium_battery_color=\"yellow\" Low battery level colour The colour used for a low battery level (10% to 0%) low_battery_color=\"red\"","title":"Theming"},{"location":"contribution/documentation/","text":"Documentation When should documentation changes be done? Whenever a new feature is added, a bug is fixed, or a breaking change is made, it should be documented where appropriate (ex: README.md , changelog, etc.) New methods of installation are always appreciated and should be documented What pages need documentation? There are a few areas where documentation changes are often needed: The extended documentation (AKA here) The README.md The help menu inside of the application (located here ) The CHANGELOG.md How should I add documentation? Fork the repository first and make changes there. Where you're adding documentation will probably affect what you need to do: ### README.md or CHANGELOG.md For changes to README.md and CHANGELOG.md , just follow the formatting provided and use any editor. ### Help menu For changes to the help menu, try to refer to the existing code within src/constants.rs on how the help menu is generated. ### Extended documentation For changes to the extended documentation, you'll probably want MkDocs , Material for MkDocs , mdx_truly_sane_lists , and optionally Mike installed to provide live reloading and preview for your changes. They aren't needed but it'll help with validating your changes. You can do so through pip or your system's package managers. If you use pip , you probably would want to do something like so through a venv: # Starting from the repo root: cd docs/ # Create venv and activate python -m venv venv source venv/bin/activate # Install requirements pip install -r requirements.txt # Run mkdocs venv/bin/mkdocs serve Once you have your documentation changes done, submit it as a pull request. For more information regarding that, refer to Issues, Pull Requests, and Discussions .","title":"Documentation"},{"location":"contribution/documentation/#documentation","text":"","title":"Documentation"},{"location":"contribution/documentation/#when-should-documentation-changes-be-done","text":"Whenever a new feature is added, a bug is fixed, or a breaking change is made, it should be documented where appropriate (ex: README.md , changelog, etc.) New methods of installation are always appreciated and should be documented","title":"When should documentation changes be done?"},{"location":"contribution/documentation/#what-pages-need-documentation","text":"There are a few areas where documentation changes are often needed: The extended documentation (AKA here) The README.md The help menu inside of the application (located here ) The CHANGELOG.md","title":"What pages need documentation?"},{"location":"contribution/documentation/#how-should-i-add-documentation","text":"Fork the repository first and make changes there. Where you're adding documentation will probably affect what you need to do: ### README.md or CHANGELOG.md For changes to README.md and CHANGELOG.md , just follow the formatting provided and use any editor. ### Help menu For changes to the help menu, try to refer to the existing code within src/constants.rs on how the help menu is generated. ### Extended documentation For changes to the extended documentation, you'll probably want MkDocs , Material for MkDocs , mdx_truly_sane_lists , and optionally Mike installed to provide live reloading and preview for your changes. They aren't needed but it'll help with validating your changes. You can do so through pip or your system's package managers. If you use pip , you probably would want to do something like so through a venv: # Starting from the repo root: cd docs/ # Create venv and activate python -m venv venv source venv/bin/activate # Install requirements pip install -r requirements.txt # Run mkdocs venv/bin/mkdocs serve Once you have your documentation changes done, submit it as a pull request. For more information regarding that, refer to Issues, Pull Requests, and Discussions .","title":"How should I add documentation?"},{"location":"contribution/issues-and-pull-requests/","text":"Issues, Pull Requests, and Discussions Discussions Discussions are open in the repo . As for the difference between discussions and issues: Open an issue if what you have enough information to properly fill out any details needed for a report or request. Open a discussion otherwise (e.g. asking a question). Opening an issue Bug reports When filing a bug report, please use the bug report template and fill in as much as you can. It is incredibly difficult for a maintainer to fix a bug when it cannot be reproduced, and giving as much detail as possible generally helps to make it easier to reproduce the problem! Feature requests Please use the feature request template and fill it out. Remember to give details about what the feature is along with why you think this suggestion will be useful. Also please check whether or not an existing issue has covered your specific feature request! Pull requests The expected workflow for a pull request is: Fork the project. Make your changes. Make any documentation changes if necessary - if you add a new feature, it'll probably need documentation changes. See here for tips on documentation. Commit and create a pull request to merge into the master branch. Please follow the pull request template . Ask/wait for a maintainer to review your pull request. Check if tests pass. These consist of clippy lints, rustfmt checks, and basic tests. If changes are suggested or any comments are made, they should probably be addressed. Once it looks good, it'll be merged! Note that generally , PRs are squashed, though feel free to ask otherwise if that isn't preferable.","title":"Issues, Pull Requests, and Discussions"},{"location":"contribution/issues-and-pull-requests/#issues-pull-requests-and-discussions","text":"","title":"Issues, Pull Requests, and Discussions"},{"location":"contribution/issues-and-pull-requests/#discussions","text":"Discussions are open in the repo . As for the difference between discussions and issues: Open an issue if what you have enough information to properly fill out any details needed for a report or request. Open a discussion otherwise (e.g. asking a question).","title":"Discussions"},{"location":"contribution/issues-and-pull-requests/#opening-an-issue","text":"","title":"Opening an issue"},{"location":"contribution/issues-and-pull-requests/#bug-reports","text":"When filing a bug report, please use the bug report template and fill in as much as you can. It is incredibly difficult for a maintainer to fix a bug when it cannot be reproduced, and giving as much detail as possible generally helps to make it easier to reproduce the problem!","title":"Bug reports"},{"location":"contribution/issues-and-pull-requests/#feature-requests","text":"Please use the feature request template and fill it out. Remember to give details about what the feature is along with why you think this suggestion will be useful. Also please check whether or not an existing issue has covered your specific feature request!","title":"Feature requests"},{"location":"contribution/issues-and-pull-requests/#pull-requests","text":"The expected workflow for a pull request is: Fork the project. Make your changes. Make any documentation changes if necessary - if you add a new feature, it'll probably need documentation changes. See here for tips on documentation. Commit and create a pull request to merge into the master branch. Please follow the pull request template . Ask/wait for a maintainer to review your pull request. Check if tests pass. These consist of clippy lints, rustfmt checks, and basic tests. If changes are suggested or any comments are made, they should probably be addressed. Once it looks good, it'll be merged! Note that generally , PRs are squashed, though feel free to ask otherwise if that isn't preferable.","title":"Pull requests"},{"location":"contribution/packaging-and-distribution/","text":"Packaging and Distribution Package maintainers are always welcome and appreciated! Here's some info on how one can help with package distribution and bottom. Pre-built binaries The latest stable release can be found here , where you can find pre-built binaries in either a tar.gz or zip format. Binaries here also include automatically generated shell completion files for zsh, bash, fish, and Powershell, which you may want to also install during the packaging process. You can also find a nightly build in the releases page , built every day at 00:00 UTC off of the master branch. Building manually If you want to manually build bottom rather than distributing a pre-built binary, you'll need the most recent version of stable Rust, which you can get with: rustup update stable You'll then want to build with: cargo build --release --locked Manpage and completion generation bottom uses a build.rs script to automatically generate a manpage and shell completions for the following shells: Bash Zsh Fish Powershell Elvish If you want to generate manpages and/or completion files, set the BTM_GENERATION env var to a non-empty value. For example, run something like this: BTM_GENERATE = true cargo build --release --locked This will automatically generate completion and manpage files in target/tmp/bottom/ . If you wish to regenerate the files, modify/delete either these files or set BTM_GENERATE to some other non-empty value to retrigger the build script. For more information, you may want to look at either the build.rs file or the binary build CI workflow . Adding an installation source Once you've finished your installation source, if you want to mention it in the main bottom repo, fork the repo and add the installation method and any details to the README.md file under the Installation section. Once that's done, open a pull request - these will usually be approved of very quickly. You can find more info on the contribution process here .","title":"Packaging and Distribution"},{"location":"contribution/packaging-and-distribution/#packaging-and-distribution","text":"Package maintainers are always welcome and appreciated! Here's some info on how one can help with package distribution and bottom.","title":"Packaging and Distribution"},{"location":"contribution/packaging-and-distribution/#pre-built-binaries","text":"The latest stable release can be found here , where you can find pre-built binaries in either a tar.gz or zip format. Binaries here also include automatically generated shell completion files for zsh, bash, fish, and Powershell, which you may want to also install during the packaging process. You can also find a nightly build in the releases page , built every day at 00:00 UTC off of the master branch.","title":"Pre-built binaries"},{"location":"contribution/packaging-and-distribution/#building-manually","text":"If you want to manually build bottom rather than distributing a pre-built binary, you'll need the most recent version of stable Rust, which you can get with: rustup update stable You'll then want to build with: cargo build --release --locked","title":"Building manually"},{"location":"contribution/packaging-and-distribution/#manpage-and-completion-generation","text":"bottom uses a build.rs script to automatically generate a manpage and shell completions for the following shells: Bash Zsh Fish Powershell Elvish If you want to generate manpages and/or completion files, set the BTM_GENERATION env var to a non-empty value. For example, run something like this: BTM_GENERATE = true cargo build --release --locked This will automatically generate completion and manpage files in target/tmp/bottom/ . If you wish to regenerate the files, modify/delete either these files or set BTM_GENERATE to some other non-empty value to retrigger the build script. For more information, you may want to look at either the build.rs file or the binary build CI workflow .","title":"Manpage and completion generation"},{"location":"contribution/packaging-and-distribution/#adding-an-installation-source","text":"Once you've finished your installation source, if you want to mention it in the main bottom repo, fork the repo and add the installation method and any details to the README.md file under the Installation section. Once that's done, open a pull request - these will usually be approved of very quickly. You can find more info on the contribution process here .","title":"Adding an installation source"},{"location":"contribution/development/build_process/","text":"Build Process Warning This section is currently somewhat WIP. Warning This section is intended for people who wish to work on/build/distribute bottom, not general users. Overview bottom manages its own binary builds for nightly and stable release purposes. The core build workflow is handled by build_releases.yml , called by a wrapper workflow for nightly and stable releases. Builds take place via GitHub Actions. The main things built are: Binaries for various platforms MSI installer for Windows .deb package for Debian and its derivatives This documentation gives a high-level overview of the build process for each part. For the most up-to-date and detailed reference, definitely refer back to the build_releases.yml file. Binaries Binaries are built currently for various targets. Note that not all of these are officially supported. The following general steps are performed: Set up the Rust toolchain for the action runner. Enable cache. Build a release build with: --features deploy , which disables unneeded dev features in bottom. --locked to lock the dependency versions. The following env variables set: BTM_GENERATE: true COMPLETION_DIR: \"target/tmp/bottom/completion/\" MANPAGE_DIR: \"target/tmp/bottom/manpage/\" These generate the manpages and shell completions (see Packaging for some more information). Bundle the binaries and manpage/completions. Cleanup. Some builds use cross to do cross-compilation builds for architectures otherwise not natively supported by the runner. MSI This builds a full Windows installer using cargo-wix . This requires some setup beforehand with some dependencies: Net-Framework-Core (handled by Powershell) wixtoolset (handled by chocolatey) Rust toolchain After that, cache is enabled, and cargo wix takes care of the rest. .deb Currently, .deb files are built for x86 and ARM architectures ( armv7 , aarch64 ). This is handled by cargo-deb . For x86, this is handled natively with just cargo-deb . For ARM, this uses a Docker container, cargo-deb-arm , which correctly sets the dependencies and architecture for the generated .deb file. There are additional checks via dpkg to ensure the architecture is correctly set.","title":"Build Process"},{"location":"contribution/development/build_process/#build-process","text":"Warning This section is currently somewhat WIP. Warning This section is intended for people who wish to work on/build/distribute bottom, not general users.","title":"Build Process"},{"location":"contribution/development/build_process/#overview","text":"bottom manages its own binary builds for nightly and stable release purposes. The core build workflow is handled by build_releases.yml , called by a wrapper workflow for nightly and stable releases. Builds take place via GitHub Actions. The main things built are: Binaries for various platforms MSI installer for Windows .deb package for Debian and its derivatives This documentation gives a high-level overview of the build process for each part. For the most up-to-date and detailed reference, definitely refer back to the build_releases.yml file.","title":"Overview"},{"location":"contribution/development/build_process/#binaries","text":"Binaries are built currently for various targets. Note that not all of these are officially supported. The following general steps are performed: Set up the Rust toolchain for the action runner. Enable cache. Build a release build with: --features deploy , which disables unneeded dev features in bottom. --locked to lock the dependency versions. The following env variables set: BTM_GENERATE: true COMPLETION_DIR: \"target/tmp/bottom/completion/\" MANPAGE_DIR: \"target/tmp/bottom/manpage/\" These generate the manpages and shell completions (see Packaging for some more information). Bundle the binaries and manpage/completions. Cleanup. Some builds use cross to do cross-compilation builds for architectures otherwise not natively supported by the runner.","title":"Binaries"},{"location":"contribution/development/build_process/#msi","text":"This builds a full Windows installer using cargo-wix . This requires some setup beforehand with some dependencies: Net-Framework-Core (handled by Powershell) wixtoolset (handled by chocolatey) Rust toolchain After that, cache is enabled, and cargo wix takes care of the rest.","title":"MSI"},{"location":"contribution/development/build_process/#deb","text":"Currently, .deb files are built for x86 and ARM architectures ( armv7 , aarch64 ). This is handled by cargo-deb . For x86, this is handled natively with just cargo-deb . For ARM, this uses a Docker container, cargo-deb-arm , which correctly sets the dependencies and architecture for the generated .deb file. There are additional checks via dpkg to ensure the architecture is correctly set.","title":".deb"},{"location":"contribution/development/deploy_process/","text":"Deploy Process Warning This section is currently WIP. Warning This section is intended for people who wish to work on/build/distribute bottom, not general users. Overview bottom currently has two main deploy processes to worry about: Nightly : a daily (00:00 UTC) GitHub action to build binary/installer files, and upload them to the nightly release . It can also be triggered manually as either a proper nightly release or a mock release. Stable : a stable deployment, triggered manually or upon creation of a valid tag. This is a GitHub action that builds binary/installer files and uploads them to a new GitHub release. Furthermore, this workflow does not handle the following deployments, which must be manually handled: Chocolatey crates.io Nightly This is, for the most part, automatic, though it can also be used as a way of testing build workflow changes and seeing if binaries can be successfully built at all against all the targets we want to build for. If one does not want to actually update the nightly release, and just want to test the general builds and workflow, one can run the workflow manually on a branch of choice with \"mock\" set as the parameter. Changing it to anything else will trigger a non-mock run. Stable This can be manually triggered, though the general use-case is setting a tag of the form x.y.z (after checking everything is good, of course). For example: git tag 0 .6.9 && git push origin 0 .6.9 This will automatically trigger the deployment workflow, and create a