Skip to content

fix: scale-aware viewport units and restore/extend Open editor - #17

Merged
b404dev merged 2 commits into
mainfrom
fix/scale-and-editor-launch
Sep 3, 2026
Merged

b404dev merged 2 commits into
mainfrom
fix/scale-and-editor-launch

Conversation

@b404dev

@b404dev b404dev commented Sep 3, 2026

Copy link
Copy Markdown
Owner

Summary

Two fixes bundled together, both regressions/gaps in the last release:

1. Text & UI scale looked "horrible" / didn't shift properly
The scale control transforms .shell, but the stylesheets use vh/vw in ~60 places (modals, the code pane, splash screen, responsive clamps). Those units always measure against the real, unscaled window regardless of an ancestor's transform, so at any scale other than 100% those elements stopped lining up with everything else that scales via the transform. Fixed by introducing --vh/--vw custom properties (1% of the true viewport, divided by the active scale) and rewriting every vh/vw literal to use them via calc(), so viewport units now scale in lockstep with the rest of the UI.

2. Open editor still doesn't work on macOS
Root cause turned out to be two separate things:

  • PR fix: resolve git and gh from GUI-launch locations #14 merged an outdated commit of its own branch — gh pr view 14 --json commits shows only 2 commits, not the 3rd one (a56d3d8) that actually contained the ExecutablePath fix for OpenInEditor. It shipped in the v0.1.15 changelog and its own now-orphaned branch, but never actually reached main. Restored here.
  • Even with that fix, an editor configured as code with no CLI shim installed (VS Code's "Shell Command: Install 'code' command in PATH" never run) has no binary to find anywhere — ExecutablePath can't invent one. Added a macOS-only fallback: when the binary truly can't be found, launch the application directly via open -a "<App Name>" for a short list of common editors (VS Code, VS Code Insiders, Cursor, Sublime Text, Zed, WebStorm, IntelliJ IDEA, Atom), forwarding any extra configured flags via --args.

Test plan

  • go build ./backend/..., go vet ./backend/...
  • go test ./backend/... — restored TestOpenInEditorUsesExecutablePathFallbacks (lost the same way as the fix itself) and added TestMacEditorLaunchArgumentsResolvesKnownApplications / TestMacEditorLaunchArgumentsForwardsExtraFlags; the 4 other failing tests are pre-existing/environment-dependent (present on main too)
  • npx tsc -b, npm run build, npm test all clean
  • make build (real wails build) succeeds end-to-end
  • Not visually verified in a running desktop session (no display available in this environment) — please confirm the scale slider now feels consistent across its range, and that Open editor launches VS Code

The Text & UI scale control transforms .shell, but every vh/vw value
in the stylesheet still measured against the real, unscaled window,
so modals, the code pane, and the splash screen stopped lining up
with everything else at any scale other than 100%. Introduces --vh/
--vw custom properties (1% of the true viewport divided by the active
scale) and rewrites every vh/vw literal to use them, so viewport units
scale in lockstep with the rest of the UI.
PR #14 merged an outdated commit of its own branch, so the
ExecutablePath-based fix for Open editor never actually reached main
even though it shipped in v0.1.15's changelog and its own PR. Restores
it, and adds a macOS fallback: when the configured editor's CLI binary
can't be found anywhere (for example "code" with the VS Code shell
command never installed), launch the application directly with
`open -a`, forwarding any extra configured flags via --args.
@b404dev
b404dev merged commit d6aae60 into main Sep 3, 2026
1 check passed
@b404dev
b404dev deleted the fix/scale-and-editor-launch branch September 3, 2026 13:46
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.

1 participant