HeaderLayout UX: Remember the meters' original column numbers until exit

[Explorer09]

This can be a UX improvement to the "Header layout" settings in the Setup screen.

1. Start htop with the default htop settings. There should be 2 meter columns.
2. Go to Setup -> Header layout
3. Change the layout to "1 column - full width"
4. Change the layout back to "2 columns - 50/50 (default)"
5. Observe that the meters that originally reside in the second column move to the first column, and they don't move back.

Expected result: The meters' original column numbers are remembered, and move back to their original column once the HeaderLayout has enough number of columns to do so. The original column numbers do not need to be remembered forever, but they should be remembered until any meter is moved in the "Meters" setting, or until htop exits.

2026-04-06.4.31.29.mov

[ugolnikovE]

I'd like to work on this.

I traced the root cause to the else branch in Header_setLayout: when the column count decreases, meters from the extra columns are appended to the last remaining one and the originals are deleted - so there's nothing left to restore from.

My proposed approach:

• Add two fields to Header: the previous HeaderLayout and an array storing how many meters each column originally had.
• In Header_setLayout, before collapsing, save these values. When the layout is changed back, use them to split meters into their original columns.
• In MetersPanel_eventHandler and AvailableMetersPanel_eventHandler, reset the saved state whenever the user manually moves, adds, or removes a meter.

Two open questions:

1. Is Header the right place to store this, or would it fit better somewhere else?
2. What should happen in a scenario like 2 -> 1 -> 4? Should we restore the saved 2-column state and then expand to 4, or only restore when the user returns to the exact same layout?

[Explorer09]

2. What should happen in a scenario like 2 -> 1 -> 4? Should we restore the saved 2-column state and then expand to 4, or only restore when the user returns to the exact same layout?

Restore the saved 2-column state and then expand to 4.

Ideally you don't need to remember what the original HeaderLayout has. Instead, keep all the allocated Header.columns[n] and remember the maxinum number of columns that the Header has internally allocated. During rendering, all meters in Header.columns[n] where n is greater than the current HeaderLayout number of columns will be placed in the last column.

[ugolnikovE]

Thanks for the suggestion - this simplifies things a lot compared to my original approach.

For rendering, my plan is to modify Header_draw so that when it reaches the last visible column, it also iterates over any hidden columns beyond it and draws their meters below the visible ones.

I've been thinking about what happens when the user opens Setup -> Meters while in a reduced layout. Currently CategoriesPanel_makeMetersPage creates panels based on HeaderLayout_getColumns, so with a 1-column layout it would only create one panel backed by columns[0]. The hidden columns[1] wouldn't get a panel, meaning the user would see all meters on the main screen, but only a subset in the editor. This could be confusing.

I see two ways to handle this:

1. Collapse on entering the Meters editor. When CategoriesPanel_makeMetersPage runs, first collapse all hidden columns into visible ones and reset maxColumns. The user then sees and edits everything in one place. The downside is that just entering and exiting Setup → Meters without changing anything would still lose the saved positions.
2. Collapse on any manual edit. Add a helper function that collapses hidden columns, and call it from MetersPanel_eventHandler / AvailableMetersPanel_eventHandler on any meter modification. This preserves saved positions until the user actually changes something, but means the editor shows fewer meters than the main screen until that first edit happens.

I'm leaning toward first way for simplicity, but wanted to get your thoughts. Does either approach sound right?

[Explorer09]

I've been thinking about what happens when the user opens Setup -> Meters while in a reduced layout. Currently CategoriesPanel_makeMetersPage creates panels based on HeaderLayout_getColumns, so with a 1-column layout it would only create one panel backed by columns[0]. The hidden columns[1] wouldn't get a panel, meaning the user would see all meters on the main screen, but only a subset in the editor. This could be confusing.

I see two ways to handle this:

1. Collapse on entering the Meters editor. When CategoriesPanel_makeMetersPage runs, first collapse all hidden columns into visible ones and reset maxColumns. The user then sees and edits everything in one place. The downside is that just entering and exiting Setup → Meters without changing anything would still lose the saved positions.
2. Collapse on any manual edit. Add a helper function that collapses hidden columns, and call it from MetersPanel_eventHandler / AvailableMetersPanel_eventHandler on any meter modification. This preserves saved positions until the user actually changes something, but means the editor shows fewer meters than the main screen until that first edit happens.

I'm leaning toward first way for simplicity, but wanted to get your thoughts. Does either approach sound right?

For the UX perspective, neither is ideal.

The user should see the collapsed columns when viewing the meters in the editor, however, the system secretly remembers the original columns of the meter, so that if the HeaderLayout changes but the meters in the editor, the meters can restore their original column positions.

The implementation can work like this:

Upon entry of the Meter editor:

• Copy the meters in the hidden column to the last visible column. Do not delete the meter references in the hidden columns yet.
• If user adds, removes or repositions a meter in the editor:
  • Remove the meter references in the hidden columns and free the buffers of the hidden columns. This means the collapsing will be permanent.
• Else, if user leaves the Meters editor while the hidden columns are still allocated:
  • Count the number of meter references inside each hidden column, and
  • Move the last of the meters in the last column back to the hidden columns, based on the counts in the previous step.