WebView Abstraction Layer and Winit about webview_rust HOT 10 CLOSED

Glutin locks us into an OpenGL rendering context, which could very well be unwanted by our users. We shouldn't use a rendering context beyond the web view, that should entirely be on the user.

For a hard counter example, Amethyst is using Tauri for their editor. Eventually, they will be rendering games in another window spawned in the same process, via our Multi-Window pattern.

from webview_rust.

Regarding Winit, it might be better to go a little higher level and use something like Glutin instead. It gives us an API to openGL and we could use it to generate custom native components on the webview window. Things like context menus and buttons. Since Glutin uses Winit in the backend, we get all of that functionality as well.

from webview_rust.

Thats fine, we can create a wrapper abstraction to allow the user to strip off glutin as a feature and use their own renderer. I just feel that it would give us some nice default patterns over using something as low level as winit.

from webview_rust.

from webview_rust.

What I would rather do is have that contained to the updater. Rendering engines aren't small, including any unless they're actually needed, or wanted by the user, is bloat, in both binary size and compile times.

from webview_rust.

Even if we want to use Glutin with a feature flag, the work for Winit so we can be sans-renderer will have to be done. It's a better default.

from webview_rust.

It turns out that WebviewGTK will not work with Winit. Solving the multi-window/GL concerns will take more research than this issue can afford at this point.

I'm handing off this work, so I'll outline what needs to be done:

1. In a new repo, we need create a set of Rust-safe bindings over ZSerge. The Rust bindgen tooling doesn't work with ZSerge, so this will have to be done by hand. After writing the extern 'C' functions, the Rust API should be minimal as to ensure the FFI-required unsafe is safely encapsulated. Where ZSerge passes a Window Pointer, we can pass null, and let ZSerge spawn the windows, until we are ready to solve the multi-window/GL concerns.

2. tauri-view can have the submodule for ZSerge removed, and that can be added to the new repo. tauri-view should wrap the new bindings with the existing abstraction in tauri-utils. Said abstraction needs window_handle removed for the time being.

3. The rest of Tauri can then be updated to use tauri_utils::WebView as the concrete wrapper around any web view stack. The bundler should default to using tauri-view, but be configurable to accept a fully-resolved type (includes crate and module path) that implements the WebViewBindingtrait.

from webview_rust.

I'll take care of building the Rust bindings to Webview.

from webview_rust.

Not sure if this should stay open, but it seemed better placed here than in the core repo.

from webview_rust.

Closing as off topic.

from webview_rust.