Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invisible Sections #74

Open
bvaisvil opened this issue Sep 27, 2020 · 6 comments
Open

Invisible Sections #74

bvaisvil opened this issue Sep 27, 2020 · 6 comments
Labels
bug Something isn't working

Comments

@bvaisvil
Copy link
Owner

Sections are treated as invisible (described here) instead of non-existent. This leads to strange problems such as TABing between sections can lead you to an invisible section.

In addition, there should be a UI way to hide and restore previously hidden sections.

@bvaisvil bvaisvil added the bug Something isn't working label Sep 27, 2020
@sumwale
Copy link
Contributor

sumwale commented Oct 3, 2020

I will be creating a separate PR for this shortly.

@sumwale
Copy link
Contributor

sumwale commented Oct 3, 2020

This seems to have been fixed in d6a1d32

@bvaisvil
Copy link
Owner Author

bvaisvil commented Oct 5, 2020

The first part is done, though we still need a UI to hide/show sections.

@alexmaco
Copy link
Contributor

Looking at other issues, like #71 and #72, and the fact that with the GPU section enabled the screen is pretty crowded already, it seems to me that zenith would benefit from a coherent window-management story. Other monitors like https://github.com/cjbassi/ytop or https://github.com/clementtsang/bottom show different takes on this issue, that there will eventually be lots of sections to display, some with history some without.

Personally, I think the process table in zenith is a very important and useful feature, and should probably always be shown by default.

A few starting ideas:

  • all display sections (apart from the process table) should have a few possible states:
    • hidden (or just reduced to a name indicator to show they still exist)
    • only showing current values (e.g. sensors in bottom)
    • showing current values and histogram (e.g. cpu usage in zenith)
  • sections may have different sampling rates or display scales
    • linear may be more useful for cpu usage, but logarithmic may be clearer for network or i/o
    • quick sample rates are relevant for cpu and network, but slower sampling rates are more relevant for filesystem usage history
  • it should be possible to allow sections to live side-by-side in a row, to allow grouping of several sections not displaying history
    • this probably makes reconfiguring the view a bit more tricky, but I think it's worth exploring

@bvaisvil
Copy link
Owner Author

I think the ideas you have here are very good. I've been considering adding more values to track (IO Ops, etc) all of which would benefit from having a consistent set of UI interactions and views. I confess that the current design has been agglomeration by trial and error.

Some specific comments below:

all display sections (apart from the process table) should have a few possible states:
hidden (or just reduced to a name indicator to show they still exist)
only showing current values (e.g. sensors in bottom)
showing current values and histogram (e.g. cpu usage in zenith)

Seems sensible. In addition, some sections will require selection of plotted values. For example, while monitoring network usage it would be useful to select which interface to monitor. This will complicate the history feature.

sections may have different sampling rates or display scales
linear may be more useful for cpu usage, but logarithmic may be clearer for network or i/o
quick sample rates are relevant for cpu and network, but slower sampling rates are more relevant for filesystem usage history

I agree with this as well. Adding varying sample rates may be a challenge with the current code. In addition, have some notion of a trend. For example, it would be useful to know that disk space has been trending downward with some idea of an acceleration rate (so you would know you have to do something about it).

it should be possible to allow sections to live side-by-side in a row, to allow grouping of several sections not displaying history

So one usefulness of the current layout I would like to maintain is that it is possible to detect coordinated changes. For example CPU usage lowering with a corresponding disk or network write. These are possible to visualize now since every section uses the same scale and timing. However, we could just add time labels.

this probably makes reconfiguring the view a bit more tricky, but I think it's worth exploring

Agreed.

One thing that has been on my mind for a bit is that code needs some reorganization. I've been meaning to split (especially render.rs into separate source files.

@bvaisvil
Copy link
Owner Author

bvaisvil commented Dec 2, 2020

This commit adds a UI to hide/show sections while zenith is running. This closes this particular issue - but I'll keep this open for the discussion regarding UI changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants