feat: say which side the second screen is on - #71
Merged
Conversation
Reported: the screen share connected and worked, and the cursor would not go to it. The obvious reading is that input forwarding is broken. It was not — the display was on the LEFT, and pushing right does nothing. macOS decides where a virtual display goes. The app asks for a size, never a position, and then said nothing at all about the result. So the one fact that determines which way you push was known to the app, visible in the window server, and absent from the interface. The popover now names the side, says to push that way, and offers the pane where the arrangement is changed — because telling somebody where a thing is without offering the way to move it is half an answer. Read back from NSScreen rather than assumed. The app does not choose the position, so the only honest source is where it actually ended up. `DisplayPlacement` is separate and pure so the decision is tested rather than eyeballed, including the one that would send the reader to exactly the wrong edge: Cocoa's y axis points up, so a greater y is physically higher. Where a display is offset on both axes, the dominant one wins, because that is the edge the cursor actually crosses. This is the same fault as the previous fix in different clothes. There, the receiver knew a session was refused and showed "Reconnecting…". Here, the sender knew where the display went and showed nothing. Each time the information exists and the interface declines to say it, and each time the user concludes the app is broken — reasonably, because from outside there is no difference. 209 Swift tests. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reported from a live session: the share connected and worked, and the cursor would not go to the second screen. The obvious reading is that input forwarding is broken.
It wasn't. The display was on the left, and pushing right does nothing.
macOS decides where a virtual display goes — the app asks for a size, never a position — and then said nothing about the result. So the one fact that determines which way you push was known to the app, sitting in the window server, and absent from the interface.
What changes
The popover now names the side, says to push that way, and offers the pane where the arrangement is changed. Telling someone where a thing is without offering the way to move it is half an answer.
The placement is read back from
NSScreen, not assumed. The app doesn't choose the position, so the only honest source is where it actually ended up.DisplayPlacementis a separate pure type so the decision is tested rather than eyeballed — including the one that would send the reader to precisely the wrong edge: Cocoa's y axis points up, so a greater y is physically higher. Where a display is offset on both axes the dominant one wins, because that's the edge the cursor actually crosses.Also a note in the README, since the default placement surprises people before they ever open the popover.
The pattern this belongs to
This is #70 in different clothes.
Every one of these is the same failure: a specific fact is known, a generic one is displayed, and the user is left to infer the difference from behaviour. They conclude the app is broken — reasonably, because from outside there is no difference between "occupied" and "broken", or between "on the other side" and "not working".
Verification
209 Swift tests, 5 of them new and covering the placement decision. The app builds. The popover row itself is not visually verified — doing that means replacing the running copy, which would interrupt the session that reported this.
🤖 Generated with Claude Code