Hardcoded popout dimensions vs dynamic content (magic numbers, no implicit sizing)

vybe commented

2026-05-19 04:19:59 +00:00

Collaborator

Problem

The popout uses fixed magic numbers:

popoutWidth: 360
popoutHeight: 400
ListView height capped at Math.min(..., 200)

Content height is dynamic (number of peers, font size, DPI scaling). The popout either wastes space on short/empty lists or artificially clips long ones. No use of implicit sizing, Theme metrics, or Layout to adapt to content.

Impact

The widget looks inconsistent across different peer counts, font sizes, and screen DPIs. The layout is fragile and requires manual tuning instead of responding to actual content.

## Problem The popout uses fixed magic numbers: - `popoutWidth: 360` - `popoutHeight: 400` - `ListView` height capped at `Math.min(..., 200)` Content height is dynamic (number of peers, font size, DPI scaling). The popout either wastes space on short/empty lists or artificially clips long ones. No use of implicit sizing, `Theme` metrics, or `Layout` to adapt to content. ## Impact The widget looks inconsistent across different peer counts, font sizes, and screen DPIs. The layout is fragile and requires manual tuning instead of responding to actual content.

jtmorris commented

2026-05-19 04:22:06 +00:00

Owner

Yes! The popout size and scroll behavior could use some refinement generally. For most users, it can probably dynamically size to fit the content. However, there should be some maximum size.

Additionally, if the content needs to scroll, there needs to be some visual indicator (i.e., a scroll bar on the right) to indicate that there is more off-screen.

Yes! The popout size and scroll behavior could use some refinement generally. For most users, it can probably dynamically size to fit the content. However, there should be some maximum size. Additionally, if the content needs to scroll, there needs to be some visual indicator (i.e., a scroll bar on the right) to indicate that there is more off-screen.

vybe commented

2026-05-19 04:57:45 +00:00

Author

Collaborator

FYI from cross-model audit (gemini-3.1-pro-preview) + research:

horizontalBarPill and verticalBarPill return raw Row/Column without an explicit Item wrapper that sets implicitWidth/implicitHeight. While Qt positioners calculate implicit sizes automatically, returning them directly from a Component can cause layout measurement issues in some shell layout engines.

This is another instance of the same class of defensive QML hygiene issues seen in #18, #19, and #32.

FYI from cross-model audit (gemini-3.1-pro-preview) + research: `horizontalBarPill` and `verticalBarPill` return raw `Row`/`Column` without an explicit `Item` wrapper that sets `implicitWidth`/`implicitHeight`. While Qt positioners calculate implicit sizes automatically, returning them directly from a `Component` can cause layout measurement issues in some shell layout engines. This is another instance of the same class of defensive QML hygiene issues seen in #18, #19, and #32.