search

evo-lua / evo-runtime

General-purpose Lua programming platform and developer toolkit
https://evo-lua.github.io
Mozilla Public License 2.0
11 stars 1 forks source link

Consider using a different WebView implementation (or creating a modified fork) to alleviate crossplatform woes #201

Open rdw-software opened 1 year ago

rdw-software commented 1 year ago

Issues such as #77 require extensive modification of the platform-specific WebView code. While I've worked around this by extending the webview engine itself, there are many other problems caused by the questionable design choices (or rather, "suboptimal for what I have in mind"), and to top it off all the OSX platform code uses the low-level ObjectiveC runtime APIs. It's definitely not fun to work with.

Another problem is that there is a need to split code between Windows, OSX, and Linux, but the current design of the library doesn't allow this at all if the C++ namespaces are required (setting WEBVIEW_HEADER removes the C implementation, but also all of the C++ namespace - WTF?). This means more hacks are required to even split platform-specific extension code in the FFI bindings.

Lastly, the webview library's "build system" is even more hodgepodge than the one I'm using here. That's far worse because it's a library intended for consumption by other projects, whereas this is a standalone executable with very deliberate limitations. While it wouldn't matter for a header-only library, it does matter for getting the WebView2 engine code (NuGet? Sigh). And header-only makes maintaining it a challenge to say the least, so that's probably another sub-optimal design choice from an outsider's perspective.

Considering that the upstream repository has been somewhat actively developed, but not actively enough to really solve these problems... and I don't want to step around all the stuff I don't need (Go bindings? Uh, yeah...),.. Maybe it's easier to either fork the library and create a simplified version that better suits this project's needs, or rewrite the WebView implementation with a different (easier to use) API? The idea is definitely solid, but I think the execution is somewhat lacking... at least in its current form.

Details TBD, this is just to collect the inital thoughts after working with both the WebView code and OSX for some time.

rdw-software commented 1 year ago

Work in progress here: https://github.com/evo-lua/evo-webview

Still some cleanup left to do, but this looks like a much more maintainable solution in the long term.