Replace winapi and webview2 crates with bindings from windows-rs#133
Replace winapi and webview2 crates with bindings from windows-rs#133wusyong merged 16 commits intotauri-apps:devfrom wravery:windows-rs
Conversation
|
Impressive 😲 |
|
Really interesting work @wravery This is another one of those reasons why I think we should really consider having a configurable bleeding edge approach that we can recommend to people. In rust its easy for us to have a branch structure like:
@jbolda - how hard would it be for us to have 2 workflows that track dev and upon merging either push to Then there is the documentation about how to actually use |
|
FYI - we have forked winit and published it to crates.io until they release a new version: Line 49 in 531f2a7 |
|
I was able to snap to the |
I wonder if bleeding edge might be better as a feature flag? Long running experimental features end up being difficult to decide when to move those into the main publish flow, and then they never end up "finishing" (at least from what I have seen). I think it would be helpful to somehow have prerelease versions published on the Version Packages PR, but it is surprisingly difficult to get it working in a cross-language way without relying on the filesystem at all. |
wusyong
left a comment
There was a problem hiding this comment.
@wravery Thanks for the PR! You are doing god's work! Just some nits and I think it's good to merge.
@jbolda @nothingismagick Since we are pushing beta on tauri, and the only thing left to be published is #92.
I guess we can publish another version first and then merge this PR.
We will have enough time to settle down windows-rs as dependency.
| use std::{convert::From, env, fs, io, path::PathBuf, process::Command}; | ||
|
|
||
| const WEBVIEW2_NAME: &str = "Microsoft.Web.WebView2"; | ||
| const WEBVIEW2_VERSION: &str = "1.0.824-prerelease"; |
There was a problem hiding this comment.
Looks like the library structure is different from the previous stable release (1.0.774.44).
Will the future stable release be the same as the current one?
There was a problem hiding this comment.
I don't know for sure, but I expect that when the WinRT APIs are released that they'll still use this structure. The Win32 files seem to be in the same place between versions, and some of this structure is deterministic for interop with other tools and Visual Studio.
This does mean using the prerelease packages until the WinRT APIs are released, though.
There was a problem hiding this comment.
I see. It should be fine we use the prerelease package.
There was a problem hiding this comment.
Do we have to ship the dlls forever? Or just until the current prerelease becomes the evergreen stable? Because I really don't want to ship that by default forever
There was a problem hiding this comment.
So I think the prerelease packages are a superset of what will eventually show up in the stable/release packages. I expect the paths/structure of the WinRT APIs to match at that point.
There was a problem hiding this comment.
Do we have to ship the dlls forever? Or just until the current prerelease becomes the evergreen stable? Because I really don't want to ship that by default forever
These take the place of WebView2Loader.dll in the Win32 APIs, which has a corresponding WebView2Loader.dll.lib static import lib. There's also a WebView2LoaderStatic.lib which would statically link them into the binary with no need for a separate DLL. Whichever mechanism it used, it was probably coming from the webview2 crate. At some point, one or both of those files had to be included in the crates, upstream and/or downstream from wry to enable the static link step and potentially to include a DLL.
The WinRT API doesn't seem to have the option of linking a static implementation though, so this PR may be introducing the requirement to ship the DLLs with the package. I'll double check what webview2 was doing here.
There was a problem hiding this comment.
It looks like webview2's behavior depends on the toolchain: https://docs.rs/webview2/0.1.0-beta.1/webview2/#webview2loader. For gnu it dynamically links and you need to include the DLL, for msvc it statically links.
There was a problem hiding this comment.
ok - the real reason why i am asking is because we absolutely do not want to be in charge of shipping standalone webviews. They must be managed by the OS. I am particularly concerned about the licensing implications of doing this. I am also worried about bundle size just exploding too...
There was a problem hiding this comment.
ok - the real reason why i am asking is because we absolutely do not want to be in charge of shipping standalone webviews. They must be managed by the OS. I am particularly concerned about the licensing implications of doing this.
Ah, I see. Here's the license for that: https://www.nuget.org/packages/Microsoft.Web.WebView2/1.0.824-prerelease/License. I don't see a conflict with MIT, but it's not exactly MIT so the license text would need to be included with the binaries. Perhaps instead of including the contents in .windows in the repo, the build.rs should just always dynamically place them there, and it ought to copy/rename the LICENSE.txt file from the NuGet package with them to the target directory so it can be included with the binaries in a downstream consumer.
I am also worried about bundle size just exploding too...
This is not the WebView2 runtime itself, just the client libraries which know how to talk to it (or to a matching browser installation). The same (separately installed) runtime requirements as the webview2 crate apply: https://docs.rs/webview2/0.1.0-beta.1/webview2/#runtime. Plus if I do switch to always building the .windows directory dynamically, there should not be much change in binary size.
No rush on my end, I don't want to derail any release plans. I'll be just as happy if this goes in to a dev branch later. |
D'oh! I just realized, a side-effect of switching to the WinRT APIs for WebView2 is that it would probably cut off support for Windows 7 and Windows 8. 😞 Between that and the other concerns about licensing and redistributing binaries, I think this should definitely be considered bleeding edge. It's promising as a way to simplify the dependency on WebView2, but there are a lot of caveats to depending on it as the only way to do that. |
Yeah, there is one other pretty well camouflaged elephant in the room, and that is our desire to work together with the PureOS ecosystem and enable "official" applications to ship to their app store. From a high level, that will require us mirroring tauri & wry source code on their gitlab - and then we have to comply with the letter and intent of strict copyleft. This includes license headers in every file and absolute clarity to the license and provenance of all "first-party" code. If you like, please feel free to start a discussion on our discord in the #wry channel so we can have a bit more of a real-time chat about this. |
There was a problem hiding this comment.
Published a new patch version and main branch to track it.
I think it's safe to merge this to dev branch.
We will have plenty amount of time to settle down until next version.
@wravery Thanks again for the help! I will be sure to visit window-rs, if there are other issues in the future.
This is a follow-up to microsoft/windows-rs#538. I'm attempting to replace the
winapiandwebview2crates on Windows withwindows-rsin WRY. Generating the bindings for both fromwindows-rsmakes them a little more consistent, and I think overall they're easier and safer to use.I tested all of the examples in this repo, and they all seem to work fully (aside from
transparentwhich does not seem to be supported on Windows yet). Thedragndropwas definitely the hardest to get working, because I needed to get the COM v-table support forDropTargetto work with thewindows-rsgenerated code. There's WIP onwindows-rsto make implementing COM objects easier in the future (microsoft/windows-rs#81), and there's an experimental API on WebView2 which won't even require implementingIDragDroponce it is stabilized. So when either of those is complete, all of that COM interop code infile_drop.rscan go.I've automated pulling down a new version of the WebView2 NuGet package as part of the
bindings/build.rsscript. My goal is to be able to just change the version string inbindings/build.rsand re-runcargoto be able to rev the version of WebView2. No more manually placing files,windows-rswill pull the DLL for the target architecture from the.windowsdirectory as part of the build and copy it to the build directory.What kind of change does this PR introduce? (check at least one)
Does this PR introduce a breaking change? (check one)
The PR fulfills these requirements:
fix: #xxx[,#xxx], where "xxx" is the issue number)If adding a new feature, the PR's description includes:
Other information:
This switches from using the released Win32 APIs for WebView2 to the still pre-release WinRT APIs for WebView2. But the tradeoff for using the pre-release APIs is that
windows-rsis able to generate more complete bindings that are not marked asunsafe.