PCP: DynamicScreens

[smalinux]

No description provided.

[BenBE]

I think some places that include config.h don't need it included. Please re-check.

[natoscott]

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

#0  0x00007ffff7a8ec4c in __pthread_kill_implementation () from /lib64/libc.so.6
#1  0x00007ffff7a3e9c6 in raise () from /lib64/libc.so.6
#2  0x00007ffff7a287f4 in abort () from /lib64/libc.so.6
#3  0x00007ffff7a2871b in __assert_fail_base.cold () from /lib64/libc.so.6
#4  0x00007ffff7a37576 in __assert_fail () from /lib64/libc.so.6
#5  0x000000000041f348 in Vector_set (this=0x713000, idx=idx@entry=0, data_=0x79ad30)
    at Vector.c:339
#6  0x00000000004134de in Panel_set (this=<optimized out>, i=i@entry=0, o=<optimized out>)
    at Panel.c:135
#7  0x000000000040c8f4 in GenericDataList_rebuildPanel (this=this@entry=0x6b08c0)
    at GenericDataList.c:85
#8  0x000000000041a07b in checkRecalculation [...]
(gdb) up 5
#5  0x000000000041f348 in Vector_set (this=0x713000, idx=idx@entry=0, data_=0x79ad30)
    at Vector.c:339
339	   assert(Object_isA(data, this->type));
(gdb) p this->type
$3 = (const ObjectClass *) 0x431700 <Process_class>

[natoscott]

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

[natoscott]

Should this be ... ?

   MainPanel_setState(panel, &state);
   MainPanel_setState(genericDataPanel, &state);

[smalinux]

@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):

htop/MainPanel.c

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

[natoscott]

@BenBE any chance you can help @smalinux here with some sample code changes to get him started on this aspect? thanks!

[BenBE]

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 …

[natoscott]

@BenBE ping - can you post that detailed writeup here when you get a free minute? :) Thanks!

[BenBE]

@smalinux The rename changes from your second commit are partially included in the first commit (e.g. look for pauseUpdate in the first commit). I think putting that refactoring commit in front and ensuring the changes there are complete is most clear to get things work out correctly. A quick test is to try and compile each commit individually and see if it builds properly.

[natoscott]

This functionality has now been incorporated into PR #1243 (after fairly substantial reworking).