This implements our concept of 'dynamic screens' in htop, with a
first use-case of pcp-htop displaying things like top-filesystem
and top-cgroups under new screen tabs. However the idea is more
general than use in pcp-htop and we've paved the way here for us
to collectively build mroe general tabular screens in core htop,
as well.
From the pcp-htop side of things, dynamic screens are configured
using text-based configuration files that define the mapping for
PCP metrics to columns (and metric instances to rows). Metrics
are defined either directly (via metric names) or indirectly via
PCP derived metric specifications. Value scaling and the units
displayed is automatic based on PCP metric units and data types.
This commit represents a collaborative effort of several months,
primarily between myself, Nathan and BenBE.
Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
Signed-off-by: Nathan Scott <nathans@redhat.com>
This commit refactors the Process and ProcessList structures such
they each have a new parent - Row and Table, respectively. These
new classes handle screen updates relating to anything that could
be represented in tabular format, e.g. cgroups, filesystems, etc,
without us having to reimplement the display logic repeatedly for
each new entity.
The main change is the header hight being not included in y1.
This is important if a sub-manager gets resized, e.g. a resize while
editing the Settings or in a pickFromVector selection, and afterwards,
then the sub-manager is closed, the super-ScreenManager gets resized, it
uses the correct header hight.
The header hight might have been changed since the last resize of the
super-manager in the Settings by adding/removing some meters.
This fixes new meters being hidden after added at runtime after a resize
in the main window.
This prefers the `#if defined()` syntax over the `#ifdef` variant
whenever there's also a `#elif defined()` clause, thus making the
multiple branching structure more obvious and the overall use
more consistent.
Support three settings:
- Always show Function Bar
- Always hide the Function Bar, except in Infoscreens (Env/Locks...)
and when editing the search and filter mode
- Hide the Function Bar on ESC until the next user input
Closes: #439
Numbering from one is idiosyncratic and inconsistent with basically
everything else in the world; it doesn't make much sense as default
behavior.
All naming is updated to reflect that numbering from one is a
non-default, opt-in option. The old label of the flag saved in htoprc
("cpu_count_from_zero") is still supported for backwards compatibility
with existing configs, however.
Reasoning:
- implementation was unsound -- broke down when I added a fairly
basic macro definition expanding to a struct initializer in a *.c
file.
- made it way too easy (e.g. via otherwise totally innocuous git
commands) to end up with timestamps such that it always ran
MakeHeader.py but never used its output, leading to overbuild noise
when running what should be a null 'make'.
- but mostly: it's just an awkward way of dealing with C code.
The option is only implemented on Linux. On other platforms, and on Linuxes
that do not expose the relevant sysfs file, the frequency will be 0.
The "CPU average" meter does not show a frequency, only
the individual per-CPU meters.