Skip to content

[AI-assisted proposal] Native anchored popup renderers on Windows #29

Description

@Rizumu85

Summary

Would you be open to native owned popup windows for GPUIX on Windows?

I needed this for a compact desktop app whose select menu must extend beyond the fixed-size parent window. Rendering the menu inside the parent clips it; opening an ordinary second window gives it the wrong ownership, focus, taskbar, and positioning behavior.

This implementation was developed with Codex assistance, then integrated and manually exercised in a real downstream app. I understand the behavior and am happy to revise the implementation myself. I am opening an issue first, as requested by the contribution policy, rather than sending an unsolicited PR.

Proposed behavior

A second renderer can be initialized as a transparent native popup owned by the first renderer:

  • anchor placement is expressed in the parent window's logical pixels;
  • the backend applies flip, slide, and resize constraints to keep it on screen;
  • the popup has an owner and no independent taskbar presence;
  • transparent DirectComposition output preserves anti-aliased rounded corners;
  • focus: false opens without activating the popup;
  • closing the popup leaves the parent renderer running;
  • scrolling is routed to the popup renderer's own GpuixView.

The intended API is renderer.getWindowId() plus an anchoredPopup option on the child renderer.

Why the changes span GPUI and GPUIX

The work is one user-facing capability, but it has two implementation layers:

  1. GPUI / gpui_windows

    • implements Windows anchored popup windows;
    • includes a small follow-up fix so WS_EX_NOACTIVATE follows WindowOptions.focus, not the popup grab flag.
  2. GPUIX

    • exposes the popup options and parent window ID to JavaScript;
    • supports multiple Windows renderers on one GPUI application host;
    • adds lifecycle, positioning, transparency, and per-renderer scrolling behavior;
    • includes an example, documentation, and a changeset.

These are tightly coupled, so I kept them together in this proposal. If you prefer separate implementation PRs after approving the direction, I can split them along the two layers above.

Working branches

The branches are a validated proof of the direction, not a claim that they are ready to merge unchanged. Before any invited PR, I would rebase, remove generated artifacts from the hand-edited diff, follow the requested split, and include the full agent disclosure required by this repository.

Validation so far

The downstream Windows app builds and uses the popup for a long, scrollable select menu outside its compact parent window. Manual checks covered ownership, focus preservation, dismissal, scrolling, screen-edge placement, transparent rounded corners, and repeated open/close cycles.

Would this direction fit GPUIX? If so, which split would you prefer for the invited PR(s)?

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions