Embedding into an existing application

[ales-tsurko]

Is your feature request related to a problem? Please describe.

There're use cases when you need to embed the window/view into an existing application. For example, AU/VST plugins where the host gives you a handle to the window or a view and you should make your window/view a child/subview of it. It looks like for Windows you can use existing API of winit to make the window a child window of another. And possibly you can run the event loop somehow (for VST there's and idle function for stuff like that). But things work differently on macOS. There you need an NSView so winit becomes a redundancy. And I don't know how it works on Linux. You can check out this issue for more info.

It's a well-known issue in the Rust Audio community.

Describe the solution you'd like

I'm not familiar with the framework infrastructure for now to propose an exact solution. But that would be great to have some data structure (the window/view itself) which has a method to make it a child of a window or a subview of another view. For Windows (and, possibly, Linux) you also need a method to make a step of the event loop, but for macOS you don't need it.

Describe alternatives you've considered

If you can provide the actual handle to the view/window, it's almost done (still there's the event loop issue), because at least it could be possible to do this natively in an unsafe manner or with FFI.

Additional context

Here's an example of the embedded web-view (this fork includes macOS): https://github.com/mikesoylu/rust-vst-gui

Here's Iced GUI library without winit, embedded into NSView: https://github.com/tonikasoft/iced-nsview

Here's how it's possible with Flutter on mobile platforms: https://flutter.dev/docs/development/add-to-app

Depends on webview/webview#348

[nothingismagick]

@wusyong - what do you think? This is a bit of an edge case for tauri, but it would actually AFAICT be something we'd have to do at webview && webview_rust...

[stereokai]

We are interested in a solution like this as well, for updating the UI/frontend portion of a fullscreen game from an outdated native solution into a modern fullscreen webview, but, not in a separate window, but as an integral part of the game, like games usually are :)

[nothingismagick]

One approach that I have been thinking about is to make a "no-webview" version of tauri apps - so there would be no bindings to a webview, but you could still make use of the rust api and the bundler (and forthcoming updater). It could use the "sidecar" system to load in any additional binaries you want...

But I would like to recommend that you create an RFC so that we can properly track this complex feature: https://github.com/tauri-apps/rfcs

You are welcome to add me as a sponsor.