Show hidden items in a separate bar

[coygeek]

Summary

Implements #357 by adding an opt-in Show hidden items in separate bar preference.

When enabled, Hidden Bar keeps the main menu bar collapsed and shows captured hidden menu bar items in a separate panel below the menu bar on the current display. This gives hidden items their own row instead of relying on the system menu bar having enough horizontal space.

What changed

• Added a preference to use a separate hidden-items bar.
• Captures hidden menu bar items and renders them in a dedicated below-menu-bar panel.
• Preserves the existing inline expand/collapse behavior when the preference is disabled.
• Falls back to inline expansion if Screen Recording permission is unavailable.
• Forwards clicks from the separate bar back to the original menu bar item when Accessibility permission is available.
• Keeps the normal macOS Cmd-drag configuration workflow working while the separate-bar preference is enabled.

Notes

This is a clean-room AppKit implementation. Thaw/Ice were used only as user-facing behavior references; no GPL source was copied.

The new mode may require Screen Recording permission for capture and Accessibility permission for click forwarding.

[tieubao]

Linking this to the redesign epic #366. This PR is a concrete implementation of the 'separate bar' direction (Option D in the design notes), which is the architectural fix for the icon-order, always-hidden, notch, and macOS 27 hiding clusters at once. It will be evaluated as a foundation for that epic, not only as a standalone feature. Thanks for the substantial work here.

[diazdesandi]

@tieubao since this PR is anchoring #366 (Option D), here's what we've found digging into macOS 27's menu bar model from two angles,one on this PR's capture approach, one from the SPEC-003 diagnostic in #365. Both point at the same root cause.

1. Per-item window capture (this PR's approach)

On macOS 27, individual status items are no longer independent CGS windows — their windowIDs are synthetic per-process hashes. CGWindowListCopyWindowInfo/CGWindowListCreateImage (and even the private SkyLight SLWindowListCreateImageFromArray some menu bar managers fall back to) return nothing usable for them. We hit this in Thaw too (stonerl/Thaw#687) and had to move off this approach entirely. Based on that, captureExpandedHiddenItems()'s layer == 25 window enumeration will most likely come back empty on 27 — we haven't built this branch on 27 to confirm directly, but the underlying API no longer returns per-item windows at all.

What does still work: the menu bar host process renders all status items into one transparent hosting window, which can be captured and cropped per-item using AX-reported bounds (kAXPositionAttribute/kAXSizeAttribute). Click-forwarding likely needs the same shift — AX-targeted rather than coordinate-based CGEvent posting.

2. SPEC-003 hide-mechanism diagnostic (from #365)

Ran the diagnostic from #365 on macOS 27. Output:

HideMechanism: requested=5120.0 windowWidth=5016.0 buttonWidth=5000.0 length=5120.0

length matches requested (5120), and windowWidth/buttonWidth both landed near 5000m nowhere near the un-collapsed btnHiddenLength (20). So at the NSStatusItem/window-frame API level, the inflation looks honored. But per #360, items aren't actually hidden on 27 (confirmed by several reporters, including the same SetStoreUpdateService/donation entitlement errors we're seeing too).

Both point the same direction: macOS 27 hands menu bar layout/compositing to MenuBarAgent, and APIs that used to work by manipulating CGS windows or NSStatusItem geometry no longer have the effect they used to — even when the call itself "succeeds" and reports the expected values. For #365's diagnostic specifically, this item's own length/window/button width probably isn't a reliable degrade signal; might need to check whether other status items' on-screen positions actually shift after collapse.

For #366/Option D: if the separate-bar capture is meant to anchor the redesign, it's probably worth building the capture layer around AX bounds from the start rather than window IDs, so it survives macOS 27 without a rewrite.

We're actively working through this in stonerl/Thaw#687. One promising lead so far is that BetterTouchTool's developer (fifafu) found a couple of potentially viable approaches for menu bar managers on the new macOS, both more limited than what existed before. They've shipped the first as an experiment in BTT 5.670 and are currently gathering feedback on whether it holds up across different machines.