feat: add WindowIdExt::with_window_handle for native window handle access#1080
Merged
Conversation
…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).
Collaborator
|
I think this looks reasonable. Thanks! |
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
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.
What
Adds
WindowIdExt::with_window_handle, a backend-neutral way to obtain a window's native handle from aWindowId:It runs
fwith the window'sraw_window_handle::WindowHandle, returningNoneif there is no live OS window for the id (or the platform can't produce a handle). It wraps the existing internalwith_windowand mirrors the otherWindowIdExtaccessors (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
wrychild webview viaWebViewBuilder::build_as_child(&handle). Today there is no public way to get it: the window registry (with_window) lives in thepub(crate)window::trackingmodule.raw_window_handle::WindowHandleimplementsHasWindowHandle, so it plugs straight intowry/build_as_childand similar APIs. Exposing theraw-window-handletype (already a dependency) rather than the underlyingwinit/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 backHasWindowHandle.Example
Notes
WindowIdExt; no new public types, nowinitleak.cargo clippy --libclean on currentmain.wrychild webview) inside a Floem window.