Implement different display types for bar meters by rustedusted · Pull Request #1794 · htop-dev/htop

rustedusted · 2025-10-25T12:49:06Z

Allow bar meters to enable "sub-pixel" rendering.

Bar meter styles can be changed in setup (F2) under Display Options.

Co-Authored-By: Benny Baumann BenBE@geshi.org

rustedusted · 2025-10-25T12:49:56Z

referencing with issue #647
the previous merge request was a mess

rustedusted · 2025-10-25T12:52:43Z

One more thing
the bar type option is visible in F2 even when we do htop -U should i disable it when opened with -U
or keep it there??

the function didn't have any if statement in it so felt awkward to do that
it's just a line of difference to add

rustedusted · 2025-10-25T12:55:55Z

[x] Resolve the conflict marker in the latest commit(not using the previous commit)
[x] Handle storing the setting to disk
[ ] Proper guarding against invalid barType settings in Meter.c(i do not understand this, i just put asserts in the Meter.c line 168)(please let me know if there's anything else)
[x] Handle when htop is configured without Unicode support(done using header guards #ifdef HAVE_LIBNCURSESW)
[x] Update Commit message

BenBE · 2025-10-25T14:45:16Z

         this->hideFunctionBar = atoi(option[1]);
+      #ifdef HAVE_LIBNCURSESW
+      } else if (String_eq(option[0], "bar_type")) {
+         this->barType = atoi(option[1]);


The value read here isn't protected against an invalid configuration file. Please ensure, that the value in this->barType is sanitized to be a valid bar type index.

It would be a good idea to set this->barType to 0 whenever we read an invalid value from the config. This makes the field forward-compatible to any future extensions of the list. Also, we should use strtol for parsing this field to get a defined behavior on integer overflow.

Unfortunately we don't have a macro to easily produce code like this one:

{ long value = strtol(option[1], NULL, 10); if (value < 0 || value > BAR_METER_NUM_STYLES) value = 0; this->barType = (unsigned int)value; }

BenBE · 2025-10-25T14:49:42Z

         blockSizes[i] = ceil((value / this->total) * w);
         blockSizes[i] = MINIMUM(blockSizes[i], w - offset);
+
+#ifdef HAVE_LIBNCURSESW
+         extraWidth = (int)ceil((value / this->total) * w * barLen) % barLen;
+#endif


I think this needs some minor update. The extraWidth calculation probably should re-use the value calculated in the blockSizes[i] assignments above.

BenBE · 2025-10-25T14:51:57Z

+   L"||||||||",
+   L"########",
+   L"⣿⡀⡄⡆⡇⣇⣧⣷",
+   L"█░░▒▒▓▓█",
+   L"█▏▎▍▌▋▊▉",
+   L"█▁▂▃▄▅▆▇",
+   L"█▌▌▌▌███",


Having the full block final seems more natural. Any reason to put it first and skip the per-profile blank instead?

BenBE · 2025-10-25T14:56:12Z

   Panel_add(super, (Object*) NumberItem_newByRef("Hide main function bar (0 - off, 1 - on ESC until next input, 2 - permanently)", &(settings->hideFunctionBar), 0, 0, 2));
+
+   #ifdef HAVE_LIBNCURSESW
+   Panel_add(super, (Object*) NumberItem_newByRef("Bar Type (0-6)", &(settings->barType), 0, 0, 6));


Maybe 0 = default to avoid having this needing to updated whenever there's a new character theme.

Explorer09 · 2025-10-25T16:12:47Z

   #endif
   int hideFunctionBar;  // 0 - off, 1 - on ESC until next input, 2 - permanently
+   #ifdef HAVE_LIBNCURSESW
+   int barType;


Any reason not to use unsigned int for this field?

Explorer09 · 2025-10-25T16:22:08Z

+   assert(settings->barType < ( sizeof(bars) / sizeof(wchar_t*) ));
+   assert(settings->barType >= 0);
+   const wchar_t* currBar = bars[settings->barType];
+   int barLen = (int)wcslen(currBar);


I consider this function call redundant when you have declared the list of bars to have equal length.

Not sure if this is what you intended, but I think the bar meter characters can be defined with variable widths if you wish.

Like this:

static const wchar_t* BarMeterMode_drawStyles[] = { L"|", L"#", L"⡀⡄⡆⡇⣇⣧⣷⣿", L"░▒▓█", L"▏▎▍▌▋▊▉█", L"▁▂▃▄▅▆▇█", L"▌█", };

The bars currently have all the same length, but the intention is to actually allow for bars to contain different number of symbols.

Explorer09 · 2025-10-25T16:32:40Z

+#include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
+#include <wchar.h>


Remove this include line. wchar.h is better included indirectly via ProvideCurses.h.

Explorer09 · 2025-10-25T16:34:04Z

 #include <float.h>
 #include <limits.h> // IWYU pragma: keep
 #include <math.h>
+#include <stdio.h>


I didn't see any stdio.h function being used at all in this PR.

BenBE · 2025-10-25T20:17:03Z

Please squash/fixup changes into the original commit by rebasing. Details are in the style guide.

Allow bar meters to enable "sub-pixel" rendering. Bar meter styles can be changed in setup (F2) under Display Options. Co-Authored-By: Benny Baumann <BenBE@geshi.org>

rustedusted · 2025-10-26T08:13:15Z

here's the latest commit that contains all the suggested things

BenBE · 2025-10-26T08:40:55Z

+   assert(settings->barType < ( sizeof(bars) / sizeof(wchar_t*) ));
+   assert(settings->barType >= 0);
+   const wchar_t* currBar = bars[settings->barType];
+   int barLen = (int)wcslen(currBar);


The bars currently have all the same length, but the intention is to actually allow for bars to contain different number of symbols.

BenBE · 2025-10-26T08:48:28Z

   (1 << LED_METERMODE) |             \
   0) // Avoids edits when updating

+#define BAR_METER_NUM_STYLES 7


Suggested change

#define BAR_METER_NUM_STYLES 7

extern const size_t bar_meter_num_styles;

And below the definition of bars' for the meter styles in Meter.c`:

const size_t bar_meter_num_styles = sizeof(bars) / sizeof(*bars);

This avoids an additional point of manual updating.

@BenBE This has the problem that when compiling Setting.c, compiler cannot inline the constant but has to refer to the external variable for the number. In other words, the compiled code would be sub-optimal.

I think the better approach is to move the definitions of the bar styles into the header. Look at the unitPrefixes definition in XUtils.h for what I mean.

I'm aware of this downside, but AFAICT there are no real places where looking up this constant happens inside a tight loop …

Explorer09 · 2025-10-26T09:59:04Z

-            } else {
+            }
+#ifdef HAVE_LIBNCURSESW
+            else if(CRT_utf8 && settings->barType) {


The whole block of else if (CRT_utf8 && settings->barType) { ... } can merge with the else { ... } block below so we can reduce duplicate code.

Explorer09 · 2025-10-26T10:12:25Z

   #endif
   int hideFunctionBar;  // 0 - off, 1 - on ESC until next input, 2 - permanently
+   #ifdef HAVE_LIBNCURSESW
+   unsigned int barType;


Since the proposed bar drawing styles has | (vertical bar, the default), and # (number sign), both can be drawn in ASCII-only mode, I think we can remove the #ifdef HAVE_LIBNCURSESW conditional and allow the setting to be available in both ASCII-only build and Unicode build of htop.

Note: only the first two drawing styles can be selected in ASCII. The rest can be guarded in the #ifdef HAVE_LIBNCURSESW so they require Unicode to enable:

#ifdef HAVE_LIBNCURSESW static const wchar_t* barMeterDrawStyles[] = { L"|", L"#", L"⡀⡄⡆⡇⣇⣧⣷⣿", L"░▒▓█", L"▏▎▍▌▋▊▉█", L"▁▂▃▄▅▆▇█", L"▌█", }; #else static const char* barMeterDrawStyles[] = { "|", "#" }; #endif static const size_t numBarMeterStyles = ARRAYSIZE(barMeterDrawStyles);

Explorer09 · 2025-10-26T10:28:08Z

-      for (int j = offset; j < nextOffset; j++)
+      for (int j = offset; j < nextOffset; j++) {
         if (RichString_getCharVal(bar, startPos + j) == ' ') {
            if (CRT_colorScheme == COLORSCHEME_MONOCHROME) {


There is one thing I wish to add when the feature of changing bar drawing character is added. It's this:

Suggested change

if (CRT_colorScheme == COLORSCHEME_MONOCHROME) {

if (CRT_colorScheme == COLORSCHEME_MONOCHROME && Meter_maxItems(this) != 1) {

Make the bar character changeable for meters with only one item.

--- a/Meter.h +++ b/Meter.h @@ -100,6 +100,7 @@ typedef struct MeterClass_ { #define Meter_attributes(this_) As_Meter(this_)->attributes #define Meter_name(this_) As_Meter(this_)->name #define Meter_uiName(this_) As_Meter(this_)->uiName +#define Meter_maxItems(this_) As_Meter(this_)->maxItems #define Meter_isMultiColumn(this_) As_Meter(this_)->isMultiColumn #define Meter_isPercentChart(this_) As_Meter(this_)->isPercentChart

Co-authored-by: BenBE <BenBE@geshi.org>

ygoe · 2026-05-12T10:25:04Z

+   L"⣿⡀⡄⡆⡇⣇⣧⣷",
+   L"█░░▒▒▓▓█",
+   L"█▏▎▍▌▋▊▉",
+   L"█▁▂▃▄▅▆▇",
+   L"█▌▌▌▌███"


Does this mean that there can be fractional bar blocks, i.e. the bar doesn't fill an entire character but only a part of it, increasing horizontal resolution? I know these bars primarily from the CPU meter and they have sections of different colours. While that could work for the vertically sliced blocks (foreground is the block in the left colour, background is the colour of the following section), it probably can't work with the dotted style. And still, if a bar section is shorter than a full character, such a character would need more than 2 colours and foreground/background isn't enough to properly render it.

Personally, I'd already be happy if I could replace that thin vertical line with something more filling that would stretch from the left to the right edge of the character. Doesn't need to be the whole height like █ (U+2588), could also be ■ (U+25A0) or even ▬ (U+25AC).

The technical limitations have removed the possibility of showing two colors in a single block. (In ANSI color terminal, there's no "bright" colors for background, only the foreground can be set to a "bright" color).

rustedusted force-pushed the feature-647 branch from 584ccc7 to a9b7037 Compare October 25, 2025 13:00

BenBE linked an issue Oct 25, 2025 that may be closed by this pull request

Custom character for meter (instead of "|") #647

Open

BenBE added the enhancement Extension or improvement to existing feature label Oct 25, 2025

BenBE reviewed Oct 25, 2025

View reviewed changes

Explorer09 reviewed Oct 25, 2025

View reviewed changes

rustedusted force-pushed the feature-647 branch 2 times, most recently from 39d372a to 5f1a7a9 Compare October 26, 2025 07:39

Implement different display types for bar meters

e739352

Allow bar meters to enable "sub-pixel" rendering. Bar meter styles can be changed in setup (F2) under Display Options. Co-Authored-By: Benny Baumann <BenBE@geshi.org>

rustedusted force-pushed the feature-647 branch from 5f1a7a9 to e739352 Compare October 26, 2025 08:12

BenBE reviewed Oct 26, 2025

View reviewed changes

Explorer09 reviewed Oct 26, 2025

View reviewed changes

rustedusted and others added 4 commits October 26, 2025 21:44

Update DisplayOptionsPanel.c

87f75bb

Co-authored-by: BenBE <BenBE@geshi.org>

Update Meter.c

3bd039b

Co-authored-by: BenBE <BenBE@geshi.org>

Update Meter.c

f64d0c1

Co-authored-by: BenBE <BenBE@geshi.org>

Update Meter.c

1d95f21

Co-authored-by: BenBE <BenBE@geshi.org>

ygoe reviewed May 12, 2026

View reviewed changes

	#define BAR_METER_NUM_STYLES 7
	extern const size_t bar_meter_num_styles;

	if (CRT_colorScheme == COLORSCHEME_MONOCHROME) {
	if (CRT_colorScheme == COLORSCHEME_MONOCHROME && Meter_maxItems(this) != 1) {

Uh oh!

Uh oh!

Conversation

rustedusted commented Oct 25, 2025

Uh oh!

rustedusted commented Oct 25, 2025

Uh oh!

rustedusted commented Oct 25, 2025

Uh oh!

rustedusted commented Oct 25, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BenBE commented Oct 25, 2025

Uh oh!

rustedusted commented Oct 26, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Explorer09 May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Explorer09 May 12, 2026 •

edited

Loading