feat(platform): let apps offset the window-control cluster - #312
Open
alvgaona wants to merge 2 commits into
Open
feat(platform): let apps offset the window-control cluster#312alvgaona wants to merge 2 commits into
alvgaona wants to merge 2 commits into
Conversation
A titlebar style fixes both the band's height and where the system centres the window controls in it. An app whose own header is a different height than any offered band therefore cannot line its content up with them — the only lever was picking a different band, which changes the window's whole shape (on macOS 26 the tall band also rounds the window corner harder). `WindowOptions.window_controls_offset` decouples the two: keep the band you want and put the controls on your own centreline. Declared in app.zon as `.window_controls_offset_x` / `_y`, positive right and down, zero (the default) leaving the platform's placement untouched. macOS moves the three `standardWindowButton` views; every other platform ignores it, the same honest no-op `WindowChrome.insets` already reports on the edge a platform does not use. The offset is REMEMBERED rather than applied once. AppKit relays those views out on its own schedule — entering and leaving fullscreen — so the host stores it and re-applies after each, and each apply sets an absolute origin from a captured base rather than nudging what is there, so repeated applies cannot walk the buttons across the titlebar. Nothing to add for reporting: `chromeInsetsForWindowId:` already derives `WindowChrome.buttons` by unioning the real button frames, so an app centring against the cluster sees the moved position with no second source of truth.
|
@alvgaona is attempting to deploy a commit to the Vercel Labs Team on Vercel. A member of the Team first needs to authorize it. |
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
The conversion to WindowOptions dropped the field, so imperatively created windows always got the default (0, 0) offset. The null platform now captures the offset at create, and a test covers both a window that declares one and a window that does not.
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.
Problem
I have been experimenting quite a lot with Native SDK and its macOS window management and configuration. I've reached a pain points which is that I cannot accommodate the traffic lights properly while using the property
.titlebar = "hidden_inset"inapp.zon.I wanted to have squarer corners—which
hidden_insetwould provide to me—and I wasn't able to do it because Native SDK does not (or did not) expose offset controls for the window. Below I provide some visual examples.This first image is with
.titlebar = "hidden_inset_tallwhich has rounder corners and aligns the traffic lights somewhat nice for my use case.The second image is
.titlebar = "hidden_inset"which gives us squarer corners but doesn't fit the alignment. Also, it has very tight padding around traffic lights.Fix
So now this PR tackles this issue right at its core by allowing to perfectly place the traffic lights where the user needs it to be placed. The properties are exposed are:
window_controls_offset_x (default: 0)window_controls_offset_y (default: 0)The offset is pixel-based and the origin is at the top left corner with +x to the right and +y downwards.
Note
The PR was LLM assisted, in particular the file
appkit_host.mwhere I lack experience in. I tried making the changes align the code base style and structure to the best of my ability while making this feature completely additive without removing or modifying production code.