Feat: Adjustable width proc box

[vandabbin]

Closes: #1475

This PR allows the user to adjust the width of the proc box with either keybinds, a menu setting, or in the config file.
Additionally the proc width percentage can be added to the presets with proc taking an additional option in the presets string. Old presets strings continue to work. The absence of a width percentage for a proc preset string results in it using the default value.

---

Details

Width Percentage:

• New configuration option where the proc box width percentage is defined.

  • This value is saved to the config file.

• Value can be modified in the menu and is clamped between 0 and 100.

  • screen redraws when value is changed.

• In Draw::calcSizes() the blocks that handle net and mem boxes were modified.

  • Instead of calculating width based on a static percentage it is based on a percentage value retrieved from the config.
  • If the width is larger or smaller then allowed the value is clamped into allowable range without modifying the stored value.

• Proc::width_p was made external so that it can be used as the default width setting.

Keybinds:

• Shift+Left: makes the proc box wider by 1% if it is on the right and narrower by 1% if it is on the left.

• Shift+Right: makes the proc box narrower by 1% if it on the right and wider by 1% if is on the left.

• Alt+Shift+Left: makes the proc box wider by 10% if it is on the right and narrower by 10% if it is on the left.

• Alt+Shift+Right: makes the proc box narrower by 10% if it on the right and wider by 10% if is on the left.

• Ctrl+Shift+Left: sets the proc box width to its maximum if on the right and minimum if on the left.

• Ctrl+Shift+Right: sets the proc box width to its minimum if on the right and maximum if on the left.

• Ctrl+Shift+Down: sets the proc box width to the original default from before this PR (55%)

Modifications:

• Made a change in Draw::calcSizes() to prevent process list cpu graphs from briefly vanishing while adjusting size.
• This was done with a new atomic<bool> resized inside the Proc namespace. When this value or Global::resized is true. Then the graphs inside the process list are not cleared.

Presets:

• presetsValid was modified to properly validate the presets string when proc has a 3rd option set.
• presets menu option description was updated to reflect the new option
• apply_preset was modified to apply the proc width percentage
• Changing the width with either the arrow keys or the menu sets the current_preset value back to -1
• valid formats proc:P:G or proc:P:G:W
  • proc:0:default, proc:0:default:[0-100], and proc:0:default:default

---

Benefits

This PR with the included ability to apply it in presets has benefits.

• The user has more choice in the size of the proc, mem and net boxes.
  • Allows for a view with a large proc box while still having mem and net boxes shown.
  • Allows for a very small proc box with extra large mem and net boxes.
  • Or any size in between.
  • Allows the proc box to have more space in a smaller window for potential future data columns
  • Allows more buttons in the proc box to be visible in a smaller window.
• If used in presets then it is easy to switch between various set widths.
  • This means that presets can be customized further.
  • (ex. a preset with default width proc box on the right and a preset with max width proc box on the left)
• Shift+Arrow keys give fine granularity to the setting
• Alt+Shift+Arrow keys allow for less precise adjustments (faster)
• Ctrl+Shift+Arrow keys allow for quickly setting the maximum or minimum.
• Menu option allows the user to set a precise value without having to guess.

---

Example Videos

Screen.Recording.2026-01-17.at.5.05.58.AM.mov

Screen.Recording.2026-01-19.at.12.05.16.PM.mov

[deckstose]

Not sure how complicated but if we go that far we could also think about variable widths and controlling them with the left and right arrow keys.

But in my head this already opens up the wish to refactor the drawing code into a library to allow that for more boxes...

[vandabbin]

Not sure how complicated but if we go that far we could also think about variable widths and controlling them with the left and right arrow keys.

Yeah I was already thinking about this possibility but proposed this option because it was very minimal code change.

But in my head this already opens up the wish to refactor the drawing code into a library to allow that for more boxes...

Yeah that would be really great, but is probably outside my level of experience so if this interferes with that we can just not merge this I guess

[vandabbin]

Not sure how complicated but if we go that far we could also think about variable widths and controlling them with the left and right arrow keys.

If you would prefer though I can experiment with modifiying this PR to allow for something like that

[deckstose]

Yeah I was already thinking about this possibility but proposed this option because it was very minimal code change.

The problem with these kind of ad-hoc changes (and also with the amount of new configuration options we introduced in the couple of releases) is it gets really unmaintainable really fast as it doesn't scale well.

If you're interested in this, go for it 🚀. I'd prefer it over this, but not saying I'm against this.

[vandabbin]

The problem with these kind of ad-hoc changes (and also with the amount of new configuration options we introduced in the couple of releases) is it gets really unmaintainable really fast as it doesn't scale well.

Hmm yeah I can see that. I apologize if the PRs I have been making are troublesome. I don't want to be a burden. I just like this project a lot. I can have trouble looking at the bigger picture sometimes.

If you're interested in this, go for it 🚀. I'd prefer it over this, but not saying I'm against this.

Cool I'll experiment and see what I come up with.

[deckstose]

Hmm yeah I can see that. I apologize if the PRs I have been making are troublesome. I don't want to be a burden.

No, don't think like that, you're contributions are very valuable and drive the project forward.

I didn't mean to say that a single person doing this is the problem, I have found myself in that spot as well where it's easier to just hack together some band aid solution. But at a scale we need to keep track of everything and need to rewrite the portions where a refactor makes sense.

[vandabbin]

Okay I have something going that uses a percentage value and it seems to be working well.

[vandabbin]

I believe this to be ready for final review now. I have fixed it up a couple issues and it is working great.

Oh one more edit: I made Proc::resized atomic because it wasn't working on linux unless I did so. It was working fine on my mac without being atomic though.

[vandabbin]

I guess one question I have if this pr is added is. Should the percent value also be settable in the presets?

If that was to be done the preset string would have to be thought about though. Since it might be weird for just one of the boxes to have 4 elements to the preset string. And it would need to be modified in a way that old preset strings continue to work.

I have a draft that uses a 4th element for proc in preset string and doesn't break existing presets. If the proc preset doesn't have a 4th element it uses the default width value.

valid formats:

proc:P:G or proc:P:G:W

proc:0:default, proc:0:default:[0-100], and proc:0:default:default