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.

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

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?

• 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.

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

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

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.

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:

Describe the feature request

Add colouring options + colours overall to total rx/tx

Additional context

Provide any additional context here.

@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.

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!

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.

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:

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.

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.

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

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:

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

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

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.

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.

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.

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

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

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!

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:

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)

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:

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.)

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.

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.

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:

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.

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?

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.

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

release page

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.

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.

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?

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.

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

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...

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.

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.

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:

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

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:

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

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:

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.