Skip to content

feat: add WindowIdExt::with_window_handle for native window handle access#1080

Merged
jrmoulton merged 1 commit into
lapce:mainfrom
zendy00:window-handle-accessor
Jun 21, 2026
Merged

feat: add WindowIdExt::with_window_handle for native window handle access#1080
jrmoulton merged 1 commit into
lapce:mainfrom
zendy00:window-handle-accessor

Conversation

@zendy00

@zendy00 zendy00 commented Jun 21, 2026

Copy link
Copy Markdown
Contributor

What

Adds WindowIdExt::with_window_handle, a backend-neutral way to obtain a window's native handle from a WindowId:

fn with_window_handle<F, T>(&self, f: F) -> Option<T>
where
    F: FnOnce(raw_window_handle::WindowHandle<'_>) -> T;

It runs f with the window's raw_window_handle::WindowHandle, returning None if there is no live OS window for the id (or the platform can't produce a handle). It wraps the existing internal with_window and mirrors the other WindowIdExt accessors (scale, is_visible, …), so it adds no new public types.

Why

Embedders sometimes need the parent window's native handle to attach a native child — for example embedding a wry child webview via WebViewBuilder::build_as_child(&handle). Today there is no public way to get it: the window registry (with_window) lives in the pub(crate) window::tracking module.

raw_window_handle::WindowHandle implements HasWindowHandle, so it plugs straight into wry/build_as_child and similar APIs. Exposing the raw-window-handle type (already a dependency) rather than the underlying winit/backend window keeps Floem from leaking its windowing-backend types — matching the design goal raised in #505 ("it would be a good thing if Floem doesn't directly expose winit's types"), and it should survive the planned winit → baseview abstraction since both back HasWindowHandle.

Example

use floem::window::WindowIdExt;

window_id.with_window_handle(|handle| {
    wry::WebViewBuilder::new()
        .with_url("https://example.com")
        .build_as_child(&handle)
});

Notes

  • One method on the already-public WindowIdExt; no new public types, no winit leak.
  • Compiles and cargo clippy --lib clean on current main.
  • Used downstream to embed native browser tabs (a wry child webview) inside a Floem window.
  • Related to the native-window interop discussed in Need a way to create a Floem NSView in a foreign Mac OS app #505 — this addresses the opposite direction (embedding a native child into a Floem window).

…cess

Adds a backend-neutral way to get a window's native handle from a WindowId, for
embedders that attach native children (e.g. a wry child webview via
build_as_child) to a Floem window.

with_window_handle(|handle| ...) runs a closure with the window's
raw_window_handle::WindowHandle (raw-window-handle is already a dependency) and
returns None if there's no live OS window. It wraps the existing internal
with_window and mirrors the other WindowIdExt accessors (scale, is_visible, ...),
so it does not expose Floem's windowing-backend (winit) types — matching the
design goal discussed in lapce#505. WindowHandle impls HasWindowHandle, so it plugs
straight into APIs like wry's WebViewBuilder::build_as_child(&handle).
@jrmoulton

Copy link
Copy Markdown
Collaborator

I think this looks reasonable. Thanks!

@jrmoulton jrmoulton merged commit 778bb5f into lapce:main Jun 21, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants