[schneidermilanistvan-hash]

Description

Supersedes #974, which the stale bot closed while its CI runs were still waiting for approval (first-time contributor), so they never ran.

Same feature, rebased onto current main as one commit:

• drag the bottom overlay anywhere, including past a screen edge; the position survives relaunch
• Settings → Reset Position; backups carry the position
• a position chosen on a display that was later unplugged is never restored out of reach

@altic-dev could you approve the workflows and take a look when you have time? Happy to adjust anything.

Type of Change

• 🐞 Bug fix
• ✨ New feature
• 💥 Breaking change
• 🧹 Chore
• 📝 Documentation update

Related Issue or Discussion

Relates to Discussion #625 (bottom-left/right overlay positions — dragging covers it) and #284 (free-floating overlay with a persisted, draggable position). The earlier review history is on #974.

Testing

• Tested on Intel Mac
• Tested on Apple Silicon Mac
• Tested on macOS version: 26.6.2
• Ran linter locally: swiftlint --strict on the changed files — clean apart from the existing legacy_swiftui_aspect_ratio warning that main also has
• Ran formatter locally: swiftformat --lint — no findings on any added line
• Ran tests locally: 1819 tests, including 8 new OverlayPlacementTests for display changes and past-edge positions

Screenshots / Video

• No UI/visual changes; screenshots/video are not applicable.

1. Default — anchored bottom-centre

2. Dragged into the middle of the screen

3. Dragged up against the top edge

4. Reopened after stopping and restarting dictation — still where it was dragged

Notes

• The placement helpers moved to OverlayPlacement.swift, and the drag flag now sits on BottomOverlayPanel in OverlayCloseDiagnostics.swift where main moved the panel. This keeps BottomOverlayView.swift under the 4000-line limit.
• The screenshots are from feat(overlay): let users drag the bottom recording overlay #974; the behaviour is unchanged by the rebase.
• Scope is the bottom overlay only. With no stored position, behaviour is exactly as before.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Adds dragging support to the recording overlay window.

The review raises no new finding, but the previously reported out-of-reach pill position remains a practical concern.

Summary

The PR adds a draggable, persisted position for the bottom recording overlay, a Settings reset control, backup support, and placement tests. Since the previous review, it adds a minimum visible-area check and focused tests for display changes.

_{Reviews (2) · Last reviewed commit: "fix(overlay): require a grabbable part o..."}

[github-actions]

This pull request has been marked stale because it has had no activity for 5 days. It will be closed in 2 days if there is no further activity. Add the keep-open or pinned label to prevent automatic closure.

[schneidermilanistvan-hash]

Pushed 920e18b for both Greptile findings: after a display change the overlay now needs a grabbable 44×20 pt on a screen's visible area (a 1-pt sliver used to count), and OverlayPlacementTests adds 8 cases for display changes and past-edge positions. They all pass locally; the full suite passes apart from AudioRouteRecoveryIntegrationTests, which is flaky under load and passes 3/3 on its own.

@altic-dev @grohith327 could one of you approve the workflows when you get a chance? Happy to change anything.

[github-actions]

This pull request has been marked stale because it has had no activity for 5 days. It will be closed in 2 days if there is no further activity. Add the keep-open or pinned label to prevent automatic closure.

[schneidermilanistvan-hash]

Gentle bump on this one: rebased, tests added (8 new placement cases), and the review bot's findings are fixed. If a draggable overlay is more than you want to take on, I'm happy to cut it down to a simple bottom-left / centre / right option for Discussion #625 instead.

[github-actions]

FluidVoice PR build ready

Download FluidVoice-PR-1027-920e18bd8019

The artifact contains the ad-hoc-signed app ZIP, Xcode archive, build manifest, and installation instructions. It expires 5 days after the build.

Install the app

1. Extract the downloaded artifact, then extract FluidVoice-PR-1027.app.zip.

2. Move FluidVoice feat(overlay): let users drag the bottom recording overlay #1027.app into the /Applications folder.

3. Open Terminal and remove the download quarantine marker:

   xattr -dr com.apple.quarantine "/Applications/FluidVoice #1027.app"
   

4. In Applications, Control-click FluidVoice feat(overlay): let users drag the bottom recording overlay #1027.app and choose Open.

5. If macOS still blocks it, open System Settings → Privacy & Security, click Open Anyway, and confirm.

This build has its own app identity, so its permissions are separate from the release version of FluidVoice.

View workflow run

[altic-dev]

let me look into this!

I think a hotkey hold while moving makes sense tbh - just letting this freeroam seems too open and would invite problems. Is there a way to reset it?