search

Boscop / web-view

Rust bindings for webview, a tiny cross-platform library to render web-based GUIs for desktop applications
MIT License
1.91k stars 173 forks source link

[enhancement] consume upstream webview #97

Open nothingismagick opened 4 years ago

nothingismagick commented 4 years ago

I know that this has been discussed before, but I think it is time to revisit it for a couple reasons.

First of all, there is now activity again at: https://github.com/zserge/webview/tree/webview-x

I think that it would be beneficial for the entire community if the enhancements made here were pushed back upstream.

Second - at tauri we have the need to enable other languages (like python, nim, go and others) to consume the underlying webview codebase. The way that boscop/web-view is structured at the moment makes that challenging, because of the way that the upstream source has been embedded. Basically non-rust consumers of tauri will need to pull in a rust crate / git repo to get the headers etc. in order to stay in lockstep with our api - which we for obvious reasons can't allow to use two diverging sources.

One solution might be to use a flag in the consuming Cargo.toml that allows a user of boscop/web-view to pull the source from some / any other place...

Thoughts?

nothingismagick commented 4 years ago

Reading through the code - there is the outdated option to use a custom version of webview, but this commit makes the following statement in the comment impossible:

//! To use a custom version of webview, define an environment variable `WEBVIEW_DIR` with the path
//! to its source directory.

SRC: https://github.com/Boscop/web-view/blob/master/webview-sys/lib.rs#L3-L4

nothingismagick commented 4 years ago

And maybe @zserge would like to tell us if that is even a good idea :)

richardhozak commented 4 years ago

I was more keen to go in a more rusty direction, meaning I would like to slowly port the c/c++ code to Rust and maybe provide c bindings. I think the safety that Rust would provide in this case would be beneficial for bindings created for other languages, since anything can bind to c. What do you think?

nothingismagick commented 4 years ago

We were discussing this internally this afternoon, and we could also envision providing bindings for python, go, nim et. al. from the rust core. Not having to include C in that chain would be beneficial of course. And your point is also very spot on: there is soooo much 'unsafe' going on in this crate (out of necessity of course).

We are also looking into options in our current research where we pick and choose the best parts of winit and glutin and servo and optionally offer that / those as a windowing target.

Nevertheless, I wish there was still the option right now for us to switch out the core webview with one we might choose. The simple reason is that any decision for such a refactoring (and the work accompanying it) is not likely to be trivial or done overnight.

richardhozak commented 4 years ago

We are also looking into options in our current research where we pick and choose the best parts of winit and glutin and servo and optionally offer that / those as a windowing target.

Yeah, it would be nice to be able to choose windowing target, I was also looking a bit into this, we could integrate this crate with native-window-handle crate so users can choose any windowing library.

Nevertheless, I wish there was still the option right now for us to switch out the core webview with one we might choose. The simple reason is that any decision for such a refactoring (and the work accompanying it) is not likely to be trivial or done overnight.

The main problem is that now we have backends split into multiple files and one header but zserge/webview is still one header only. I like the maintainability of separate files, but now that zserge seems to do something with webview, we would not have to maintain this anymore, just backport some fixes upstream and accept the one file.

nothingismagick commented 4 years ago

Well, we could maybe convince him to split the header like we've done...

erlend-sh commented 4 years ago

@zxey has there been any more talk about the prospect of establishing an org for web-view? You appear to have been the primary maintainer for the past year; makes sense that you and @Boscop should co-own the project in a shared org.

That'd make it much easier for projects like Tauri to coordinate with web-view, as well as enabling more collaborators to get involved to lessen the maintenance burden.

richardhozak commented 4 years ago

There hasn't been any more talk about an org, the only discussion about this can be read here: https://github.com/Boscop/web-view/issues/64