Configurable UI font size: scale look-and-feel fonts, and the constants that clip

[jcschaff]

Groundwork for a user-settable UI font size, plus the first round of layout fallout. Inert at the default scale of 1.0 — nothing changes unless -Dvcell.ui.fontScale is set.

Why this route

-Dsun.java2d.uiScale was evaluated first, since it would have made most of this unnecessary. It won't:

macOS    uiScale=null/1.5/2.0  ->  Label.font 13.0pt, pref 130x16, gcScaleX 2.00 (identical)
Linux    uiScale=null/1.5/2.0/3.0 -> Label.font 12.0pt, pref 141x15, stringWidth 141 (identical)

On macOS the JDK derives scale from the display and ignores the property outright. Where it is honored, it multiplies only the device transform — Swing lays out in logical units, which the flag never touches. That is why it can never clip, and equally why it cannot make text more readable at a fixed window size. It magnifies; it does not enlarge. Worth keeping in mind as a separate, zero-code answer to "VCell is tiny on my 4K monitor".

What this does

VCellLookAndFeel walks the look-and-feel defaults after setLookAndFeel and multiplies every Font, before any window is built — Swing components resolve their font once, at construction. Fonts are written back as FontUIResource, not plain Font: a plain one reads as a user-set override and the L&F would stop managing it.

The scaling also now runs on every platform. The existing 39-key UIManager.put block sits inside if (isMac), so Windows and Linux had no font handling at all. Scaling is applied before that block, so the Mac path derives from it rather than undoing it.

Bad input can't stop the client starting — unparseable or out-of-range values log and fall back to 1.0.

What broke at 1.25x, and why

Measured against a live client via the debug bridge — 93 components matched across two runs, 17 grew wider, 71 kept their width.

Every visible defect was in the left navigation panel: tree labels clipped with no ellipsis (Parameters, Functions, Units, etc. lost its period), counts truncated mid-digit ((538) → (53), the database tab strip pushed Pathway Comm out into scroll mode, and a spurious horizontal scrollbar appeared.

None of it came from a font. It came from splitPane.setDividerLocation(270) in DocumentEditor, pinning the panel's width in pixels. The component data is unambiguous: inside that panel LeftBottomTabbedPane, DatabaseWindowPanel and all three tree panels held their exact widths, while ModelDeleteButton (77→88) and ShowWarningsCheckBox (113→138) grew normally elsewhere. GridBag cells size from preferred size and adapt; pinned dividers don't.

Adds VCellLookAndFeel.scaleTextPixels for constants that bound text, applied to the two divider locations and two minimum sizes here. Icon sizes, insets and borders are deliberately out of scope — they should not move with the font.

After the fix at 1.25x: LeftBottomTabbedPane 264 → 332 and BioModelDbTreePanel1 222 → 290, both exactly the requested scale, and all four defects resolved.

What this deliberately does not do

The ~138 sites that construct a Font with a literal point size keep theirs — a plain Font is immune to the L&F. Converting them is the next phase.

Notably, none of those caused a visible defect at 1.25x, because most sit in layouts that adapt. That reorders the work: the pinned pixel constants matter more than the font constants. There are 26 further hard-coded setDividerLocation calls across the client that want the same treatment.

🤖 Generated with Claude Code