[Bug]: "cpu" is not affected by "use_spacer = 'left'"

[Anakiev2]

What happened?

Hi. I think when use_spacer = 'left' is used cpu should have leading spaces:

  1%
 10%
100%

Like upspeed or downspeed or diskio_read ... This issue is not for the specified version. I know it for quite some time but now I've decided to report it. So far I've used if statements to fix it.

Actual behavior:

Version

conky 1.21.5-1

Which OS/distro are you seeing the problem on?

Arch Linux

Conky config

conky.config = {
	alignment = 'bottom_left',
	background = false,
	border_width = 0,
	double_buffer = true,
	draw_outline = false,
	font = 'DejaVuSansMono Nerd Font:size=10.5',
	minimum_height = 18,
	minimum_width = 500,
	out_to_console = false,
	out_to_x = true,
	own_window = true,
	own_window_type = 'desktop',
	update_interval = 1.0,
	use_xft = true,
	max_text_width = 0,
	short_units = true,
	if_up_strictness = 'address',
	use_spacer = 'left',
};

conky.text = [[
  ${cpu cpu1}% ${cpu cpu2}% |   ${time %d.%m.%Y} |   ${time %H:%M}
]];

[Anakiev2]

Can you add the same for ${nvidia gpuutil}? Thanks.

[imul-p]

I've been looking into this as a possible good first issue to work on. From what I can tell, the CPU percentage ultimately gets rendered through percent_print, which in turn uses spaced_print with the pad_percents setting rather than use_spacer.

This means that even though spacing is applied, it follows the pad_percents logic, and doesn't make use of use_spacer like some other variables. When I have tested this however the pad_percents variable doesn't seem to adjust the precision of the value. I am thinking it instead acts as the width of the print rather than the precision of the value. Maybe a maintainer more familiar with the project or more seasoned with c++ can shed some light on this one.

[Caellian]

Sorry for late response @imul-p, it took me some time to read through the relevant code.

spaced_print is what makes variables take up more space (i.e. padded) when they're printed. use_spacer setting only sets the alignment (left, right, none) for that function.

You have to provide some max width in size argument of spaced_print.

A quick look at it, I think this line in percent_print:

return spaced_print(buf, size, "%u", pad_percents.get(*state), value);

should actually be:

return spaced_print(buf, size, "%u", std::max(pad_percents.get(*state), 4), value);

This would always pad percentage numbers to 4 chars (100% width) if use_spacer is not NO_SPACER.

Also, pad_percents documentation is wrong. There's no "decimals" involved. Format for the percentage is %u (unsigned integer), and the value passed to percent_print is unsigned. So... you can just hardcode 4 there as using pad_percents makes no sense in this (the only) context. If you go that route, make sure to update the documentation to state the setting is unused. I'm really unsure why would someone want to pad all the percentages to anything other than 4.

Or if you're feeling creative, you can rewrite percentage callback signature to return float and all stored callbacks.percentage functions (ctrl+f in core.cc). Only then would pad_percents make some sense and could be used for rounding the displayed floats - in which case instead of that std::max, you'd have to do something like:

auto padding = pad_percents.get(*state);
if (padding > 0) {
  padding += 5;
} else {
  padding = 4;
}

As a workaround, you can set pad_percents setting to 4 and cpu and friends will be displayed as expected. It should really not be 0 by default because that looks broken (by default).