Is it possible to wrap an existing window?

[LordBenjamin]

Is it possible to use winit to get a Window struct representing an existing window (not created by winit), given a RawWindowHandle?

i.e. an equivalent to the .NET NativeWindow.FromHandle(IntPtr) method

[goddessfreya]

Afaik, no.

[LordBenjamin]

Thanks for the response.

Are you able to provide any detail as to why this isn't supported?

• Outwith scope / ethos of winit
• Technically challenging / impossible
• Nobody has needed to do it yet
• Something else?

[LordBenjamin]

Looking at the implementation a bit more, the init method

• Creates a window using winuser::CreateWindowExW
• Wraps the resulting HWND using WindowWrapper(handle)
• Creates an actual Window struct using

let win = Window {
        window: real_window,
        window_state,
        thread_executor: event_loop.create_thread_executor(),
    };

Since real_window is a wrapper around the HWND, this could presumably be substituted for the handle of an existing window (within the process boundary)?

window_state looks like data that should be possible to retrieve from an existing window via the win32 API.

Not sure about thread_executor / the events loop and how this might map to an existing WindowProc. However, if the window was created externally, do we need to manage the event loop at all? (messages will presumably be being pumped by the host application)

[goddessfreya]

I don't think anyone's needed to do it before. What exactly would be the use case? Would the window be driven with winit's eventloop or be externally driven? I can't imagine this would be an easy task.

[Azorlogh]

This would be useful for audio plugins (VSTs), since they can only use the raw window handle given to them by the host.

[LordBenjamin]

What exactly would be the use case?

In a word - interop. My interest just now is mostly in using a Rust library to draw 3D graphics in a non-Rust host application. @Azorlogh's example of VST plugins is another use case.

Would the window be driven with winit's eventloop or be externally driven?

Using the .NET NativeWindow class as a reference, I'd suggest the event loop would be pumped by the host application (that created and owns the window), but that winit could subclass the window and listen to the loop, handling events on the Rust side as required.

[Osspial]

AFAIK the main use for making Winit able to handle foreign windows is so that, when Winit eventually gets a child/embeddable window API, you can parent Winit windows to foreign windows in a sane way. Is that correct? If so, it would probably be easier to have that API take a &impl HasRawWindowHandle than it would be to adapt Winit's logic to foreign-owned windows.

[LordBenjamin]

That sounds like another use case.

For me it's less about being able to parent a winit-owned window to a foreign window (or vice versa), but rather about being able to access data/events from a foreign window.

e.g.

• Create a window in C#
• Pass the window handle into a Rust library
• From the Rust library, query the window dimensions, react to the window paint events, etc for the same window that was passed in

[schell]

I would also like to use winit for my VST work, but I can't switch away from SDL2 until I can create a window from a *mut c_void:

    pub fn build_from_window_ptr<'a, 'b>(
        self,
        parent: *mut c_void,
    ) -> Result<Engine<'a, 'b>, String> {
        let sdl_context = sdl2::init()?;
        let w: *mut sdl2_sys::SDL_Window =
            unsafe { sdl2_sys::SDL_CreateWindowFrom(parent as *const c_void) };

        let window: sdl2::video::Window = {
            let video_subsystem = sdl_context.video()?;
            unsafe { sdl2::video::Window::from_ll(video_subsystem, w) }
        };

        ...
        Ok(engine)
    }

[schell]

Is there any path forward here?

[rdrpenguin04]

Ey, I'm coming here for the same reason as schell and Azorlogh: working on a VST plugin. Until this is done, it appears the best way to do this is to attempt to something with raw wgpu and re-implement various winit features, which is not ideal.

I'd be all for making winit more capable in this way.

[schell]

This is something that we will have to provide ourselves. I think a good path forward would be to create a new crate foreign-raw-window-handle which does the work of converting a *mut c_void into RawWindowHandle. I'm sure we could use the SDL2 code as a guide.

Of course, we could also write this as a patch into the raw-window-handle crate but then we would be beholden to their acceptance and release schedule. It might be just as easy to release the crate, get immediate use and then merge it to another crate later (this one or raw-window-handle).

[notgull]

This is somewhat difficult to do in real life. For something like X11, it is expected that there is only one event loop handler driving events. So you can't really trivially wrap some other X11 window with a winit window. Some other system might be trying to poll events from that window. Missing an event is annoying at best and can cause undefined behavior at worst.

The only one where it's kind of possible is Windows, where the event handler is stored in the window itself. But it requires some finesse and would still be wildly unsafe.

[daxpedda]

For Web this is already possible through WindowBuilder::with_canvas().