Pop-out and settings fixes: a restored float stays in front, picker drags float off the desktop, menus keep off the edge, settings scroll steady, the carried view is always a window (Liquid Glass on macOS 26)

[foxnne]

Bugs you found after #223 merged, one commit each.

A float restored at launch opened behind the main window. Float windows are put back over the main window whenever it comes forward: focused (the app activating), pressed, shown or restored. That check sat only in the polled event loop. Fizzy runs on SDL's callbacks on macOS, so it never ran there, and a float window was ordered over the main window only on its first show. At launch that often comes before the main window is visible. The check now runs from both event paths (noteMainForward).

A view dragged out of the place picker couldn't leave the window. The picker's drag has no source place, and floating off the desktop only took drags that had one. A view dragged out of the picker now floats where it's let go over no window, as a corner-button drag does:

• it comes out of whichever place holds it now;
• that place is its home when the float closes, and it shuts if the view left it empty;
• a view held nowhere goes home by its keywords.

Documents stay out until workspaces. Picker cards publish picker:<surface id> demo anchors.

The place picker sat flush against the window's edge. Every floating menu was placed against the bare rect of its screen, either the main window or a float's own window. Menus now stay 8 points in from its edges.

Two more, after more testing:

Settings rubber-banding. Scrolling up through the settings, the pane snapped back every few ticks. Rows out of view are skipped and keep the height they were last drawn at. A row coming back into view measured short on its first frame, because its widgets had forgotten their sizes while not drawn, then corrected itself the next frame. Everything under the row moved with it. Such a row now keeps its last height for that first frame. Scrolled back up 3000 px, the content height is identical on every frame, where before it changed every few ticks.

A carried view is a window of its own for the whole drag (macOS, float windows). Dragged off a float window, the bubble was cut off at the window's edge, then drawn behind the float once over the main window. Wherever the carry window took over, the glass also switched from refracting the app to the window's material. The carry window now shows the carried view from lift to drop, wherever it is. Over a float window it's placed by where that window sits on screen. Polled in a sandbox, it follows a drag out of a float window along its edge and on over the main window with no gap.

The carried bubble is bare material, and a float window forms out of the glass. As you asked, the carried view's window draws no base fill, so it's the OS's frosted material plus what it carries. Dialogs and float windows keep their opacity. When a float window grows out of a drop, its base fades in as it grows, reaching the window's own opacity as the real window takes over.

The carried view's content sits over the material, and a float window's content comes in as it grows. You saw the bubble's content as opaque and its fill change as invisible. Where carried things are windows, the photo is now taken without its place's background, so its content sits directly on the material. When a float grows out of a drop, the window's content arrives inside the glass as it grows (see below), not after the window appears.

A carried view is drawn by its carry window alone. A fast drag over the main window left a cutout-shaped trail. The app's own windows were still drawing a copy of the carried view under the carry window: its frosted glass, a drop's springy tail, and the drop it ran into. That copy was presented at a different moment than the window server moved the carry window, so it lagged behind. Following your rule (nothing in the app tracks the bubble unless it is all in the app), the carried view (card, tab or drop) is now drawn in a layer of its own, which the carry window takes whole (core.screens.markCarried). The main window and float windows draw nothing of it, and it has no in-app glass: the OS's material is its glass.

• The drop zones no longer run the carried drop into their glass when floats are windows. The bubble it's aimed at lights up instead, as under a pointer.
• The wobble now comes from the window. A drop's carry window covers its head and its tail as the tail lags on its spring. It stretches out behind a fast drag and swings back past when the drag stops.

Liquid Glass on macOS 26, as a drop of water. The carry window (the bubble, and the window a float grows into) uses Apple's NSGlassEffectView. AppKit's two public styles are both frosted, so the bubble showed no refracted edge. One of the glass's private variants (_variant 11, measured on 26.5) is a clear lens. It refracts what's behind it, even behind another window, with no blur, like a drop of water. The bubble uses it only on macOS 26 and only where its setter exists. Otherwise it keeps the public Clear style, and older macOS keeps the vibrancy material. The class is looked up at runtime, so fizzy still builds against older SDKs (CI's macos-14). The measurements and the plan are in #226. Merging with the drop zones as Liquid Glass is built in #227, stacked on this PR.

A float window opens cleanly out of the drop. From your captures:

• A second size flashed. The growing glass overshoots the window's frame at the playful motion level, while the real window was already fading in at its final size. The window now shows only once the glass has landed exactly at its frame.
• Text doubled near the peak. The carried photo and the window's picture crossed while each was laid out at a different size. The window's own picture now takes over in the first quarter of the growth, while the glass is small. It fills the glass with its proportions kept, so at full size it is the window's picture exactly.
• The window flared opaque at the very end. It showed under the glass while the glass faded off it, both carrying the window's base. Now the window shows and the glass goes in the same frame. The glass grows as frost, the window's own material, rather than as the carried lens.
• It opened centred on the pointer. The bubble rides below and right of the pointer, so the window now opens with its top-left corner at the bubble's and grows right and down, kept on screen.

No move cursor over a float window's traffic lights. The float's header is the area it's moved by, and it showed the move cursor everywhere, including over the OS's buttons. The drag area now starts past the window's own buttons, measured from the window each frame.

The carried bubble stands on a fifth of the window's base. With the glass a clear lens, the view's picture didn't read over whatever the bubble passed. It now has the window's base under it at 20% opacity.

The lifted place no longer goes see-through for a frame. Where floats are windows, the lift's photo is captured from the place's own draw without its background, and put back on screen for that frame. It was put back with a blend that writes the capture's clear pixels too, so the window showed the desktop through the place for one frame (your Plugins sidebar capture). It's now drawn on top of what's already there, as the place itself would be.

Verified

• zig build, zig build test, zig build test-integration (28/28 steps, 278/278 tests), zig build check-web, zig build test-sdk-version (fingerprint unchanged). Cross-builds for Windows and Linux.
• Sandboxed macOS runs:
  • Relaunched with a saved float, the main window's "shown" event now reaches the ordering check (it was dropped before), and the float stays in front.
  • A tape opens the Panel's picker and drags Output past the main window's edge. The carry window follows it out there, and a float window holding Output opens where it's let go.
  • In a frame dump, the open picker sits 8 points in from the window's right edge.
  • Holding the bubble over the main window, the main window's own picture has nothing of it. Only the carry window (window level 101) shows it.
  • Carry window bounds polled through a fast tape drag: the 104 pt bubble stretched to 142 pt behind the drag. On the stop it swung once to 137 pt and settled in about 90 ms.
  • NSGlassEffectView in a test window over a striped pattern: Clear is light with Apple's rim, Regular dark and heavily blurred. Resized every 8 ms, it stayed matched to the window. Variant 11 refracts the stripes, from a separate window too.
  • A float growing out of a drop: its window opens at alpha 0 and stays so while the glass overshoots to 386×479 and settles at 356×439. In the same poll, it shows at 356×439 and the glass window is gone. Its top edge opens at the bubble's (y 503 against 501); horizontally it was kept on screen.

Not verified:

• The app activating with a real launch (a sandbox started from a background process isn't activated by macOS). You saw that bug in your own launches.
• The wobble and the Liquid Glass bubble under a real pointer. The tapes drive dvui directly, so the speeds are the tape's.
• The vibrancy fallback on macOS before 26 (no older Mac to hand).

🤖 Generated with Claude Code