Skip to content

minimum sizes for all model controls#353

Open
saumya-pailwan wants to merge 7 commits intodevelopfrom
bug/min-control-size
Open

minimum sizes for all model controls#353
saumya-pailwan wants to merge 7 commits intodevelopfrom
bug/min-control-size

Conversation

@saumya-pailwan
Copy link
Collaborator

Summary
Previously, when the HARP window was resized horizontally, several controls would shrink below a usable width. This caused Inconsistent layout behavior across different models. The goal of this fix is to ensure a minimum size for all model control widgets so that labels, sliders, toggles, combo boxes, and text fields do not collapse or overlap when the window is resized.

Changes Introduced

  1. SliderWithLabel.h
    Added getMinimumWidth() helper to compute width based on text size.
    Ensures labels never overlap the rotary slider, even when window width shrinks.

  2. ComboBoxWithLabel.h
    Added minimum width enforcement using label text width and padding.

  3. TitledTextBox.h
    Added minimum width calculation based on title text and baseline textbox width.

  4. ControlAreaWidget.h
    Replaced hardcoded constants with dynamic minimum widths

Testing Steps
Load various models (e.g., VampNet, MegaTTS3, Stable Audio 2.0). Resize the window horizontally.

Controls no longer shrink below readable/usable size
Layout feels consistent across models
All components maintain a stable minimal-width behavior

Closes #332

@cwitkowitz
Copy link
Collaborator

cwitkowitz commented Feb 5, 2026

A few comments:

  • If we will are just going to fix a minimum size based on the label, we should create a parent ControlComponent class implementing getMinimumRequiredWidth() that each GUI component can inherit from to remove redundancy.
  • In the refactored version, I ended up using a viewport to manage scrolling the description rather than a TextEditor. Both implementations appear identical, but they both seem to suffer from the scroll bar being hidden sometimes when the HARP window is reduced beyond a certain point (i.e., below the minimum height for the scroll bar).
  • There seems to be a problem when reducing the window where the components begin to overlap with one another. See screenshot below.
Screenshot from 2026-02-05 08-30-04


if (auto* window = findParentComponentOfClass<DocumentWindow>())
{
window->setResizeLimits(900, 700, 20000, 20000);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see any noticeable difference from this line.

Copy link
Collaborator

@cwitkowitz cwitkowitz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good, but the control areas can still overlap (try with xribene/HARP-UI-TEST-v3). Maybe there is some way to extend the controls to separate rows when there would otherwise be overflow.

I also agree with making an inherited class for the ToggleComponent, but intrinsically it already has a label so the current code duplicates this (see below).

Finally, it seems the fixed minimum height can still lead to the labels on the sliders getting cut off.

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants