-
-
Notifications
You must be signed in to change notification settings - Fork 424
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
PCP: DynamicScreens #1102
PCP: DynamicScreens #1102
Conversation
0ede417
to
b23cc36
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think some places that include config.h
don't need it included. Please re-check.
@smalinux I tried building with --enable-debug and am now seeing an assert failure when I move to the first BPF tab (Opensnoop) - any ideas? It looks like the Vector_add code is checking for something that has type Process_class (and these BPF entries are not that) ...
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good @smalinux - taking htop to another level.
Do you have a list of known issues? Here's a start (no surprises here since we've chatted about these, just trying to track 'em so we can tick everything off before any merge) ...
- scaling of values needs to be more dynamic, drop from 'scale' config files
- the Available Columns from Setup should adjust per screen
- filesystem screen is a little confusing
- add a biotop screen as well
MainPanel_setState(panel, &state); | ||
//MainPanel_setState(panel, &state); | ||
panel->state = &state; | ||
genericDataPanel->state = &state; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be ... ?
MainPanel_setState(panel, &state);
MainPanel_setState(genericDataPanel, &state);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@natoscott I think we need a new panel working in parallel with/instead MainPanel. This is a big part of what I'm talking about so far...
this panel will be minimal and doesn't have Nice (f7)
or Kill (f9)
panels [dito]
This will fix a lot of issues, maybe one of them is the issue mentioned above --enable-debug
, not sure, this part needs surgery ^^"
but MainPanel has Class(Process)
:
Line 215 in bc22bee
Panel_init((Panel*) this, 1, 1, 1, 1, Class(Process), false, FunctionBar_new(Settings_isReadonly() ? MainFunctions_ro : MainFunctions, NULL, NULL)); |
also, @BenBE told me before how to do that: @natoscott I need your help here...
BenBe: I think it might be worth looking into a direction where the current Panel code is just used as a derived class ProcessListPanel (showing a process list), while most of its code is split into a base class GenericPanel (doing mostly nothing). From that GenericPanel class you could then split another derived class "FancyPanel" for doing all the Fancy stuff ;-)
Sohaib: Could you explain this more please?
BenBe: Basically what I was going at was not adopting the current Panel class to also show generic stuff, but to use the existing inheritance stuff so you can just push different kinds of Panels ("Process Lists" vs. "Generic Panels") into the list of tabs handled by the ScreenManager code.
The way to do this mostly boils down to split the current Panel implementation into the basic "draw the panel" code (extracted from current source BasePanel class) and the code drawing the process list (a new ProcessListPanel class).
The ScreenManager then instead of listing plain Panels would list BasePanels, which could be ProcessListPanels (working like they do now) or GenricStuffPanels (doing something generic).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will have to wait for next week; not in town tomorrow and the day after (giving a talk for a small conference). Changes-wise it boils down to creating inherited classes similar to what can be seen with ProcessList
and <Platform>ProcessList
with the Panel managing the ProcessList
stuff getting most of the current process list draw code. Extra points when rendering the header/list items is split in a way so that for the generic tabs and the process list the actual rendering code is the same, but only creating/filling the content buffers differs. As said, I can elaborate next week …
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BenBE ping - can you post that detailed writeup here when you get a free minute? :) Thanks!
e4f8e11
to
ba84d96
Compare
b6f0901
to
586ced4
Compare
@smalinux The rename changes from your second commit are partially included in the first commit (e.g. look for |
586ced4
to
5f02fd8
Compare
'actionTogglePauseProcessUpdate' -> 'actionTogglePauseUpdate' 'pauseProcessUpdate' -> 'pauseUpdate' 'hideProcessSelection' -> 'hideSelection' 'hideProcessSelection' -> 'hideSelection' Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
This reverts commit 821252a.
Adds support for new 'format' keyword, updates to screens config files, and some minor cleanup here & there.
87931cf
to
f65ef79
Compare
This functionality has now been incorporated into PR #1243 (after fairly substantial reworking). |
No description provided.