Desktop BrowserWindow minWidth of 840 breaks half-screen tiling on scaled displays
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 85/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- electron, typescript
- Domain
- accessibility, desktop
Research direction
Open apps/desktop/src/window/DesktopWindow.ts around line 398 and inspect how the main BrowserWindow minimum dimensions are defined. Lower the native minimum width as requested, then verify that the desktop window can tile to half-screen on scaled displays while retaining the stated minimum height.
Written by the indexing model from the issue text.
Description
Summary
The desktop app's main BrowserWindow is created with minWidth: 840 (currently around line 398 in apps/desktop/src/window/DesktopWindow.ts). This prevents the window from being tiled/snapped to exactly half of the screen on a large number of real-world displays, because the logical (post-DPI-scaling) half-screen width is often below 840px — even on physically large or high-resolution monitors.
This is not a window-manager quirk or an inherent Electron limitation: other Electron apps (e.g. Claude Code, Codex) tile correctly to half-screen on the same machines. The web version of T3 Code also has no such restriction, since it has no native window minimum.
Repro data across multiple machines
- KDE Linux, 1920 physical px @ 125% scaling → 1536 logical px → half-screen = 768 logical px. Falls short of 840.
- Windows, Dell XPS 17 (3840×2400 physical) @ 250% scaling → 1536 logical px → half-screen = 768 logical px. Falls short of 840, despite the panel being physically very large.
In both cases the issue is the same: logical half-screen width < 840, driven by the display's scaling factor, not the physical screen size. A physically huge 4K panel can still fail this check if scaling is high enough — which is common.
Why this matters for accessibility, not just small screens
DPI/text scaling isn't only used on small or old displays — many users, including older developers or those with reduced vision, deliberately run higher scaling factors (125–250%) on larger monitors for readable text. Assuming "large physical monitor = enough logical width" doesn't hold for this group. A high minWidth effectively punishes users who scale up for legibility by breaking basic window tiling for them.
Requested change
Lower the native minimum width, e.g.:
- minWidth: 840,
+ minWidth: 600,
minHeight: 620,
600 comfortably fits half-screen tiling in both scaled scenarios above while still leaving room for the app's UI. Alternatively, consider exposing this as a user-configurable setting rather than a hardcoded constant, since ideal minimums will vary by user/display.
Related
- #8849 — Text clipped on right edge when window is tiled narrower than 840px (Wayland/Linux)
- #861 — Desktop app appears too small on high-DPI displays on Windows/Linux
- Dominant language
- TypeScript
- Stars
- 23.3k
- Forks
- 6k
- Avg merge
- 10h 57m
- Merged PRs (30d)
- 365
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from pingdotgg/t3code
-
bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
accepted bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
accepted bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
accepted bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
All issues in pingdotgg/t3code
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
copse-dev/agent-pane#2953 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·