Use QTWebEngine instead of webkitgtk

[meisme-dev]

webkitgtk is slow and lacks many features (such as WebRTC). Using QTWebengine would make Tauri apps on Linux more consistent with their Windows counterparts, and open up the possibility for more apps to use Tauri over Electron.

[lencil]

or use CEF for the front web engine? tauri can support multiengine. such as webview2, wkwebview, webkitgtk, cef, something else.

[6543]

Agree i think adding support for qtwebengine and not replace webkitgtk is better for a framework, as devs can decide what fits best

[FabianLars]

I'm just gonna lazily post one of my discord messages about this into here:

qtwebengine is hard to bind to (from rust), super shit to bundle [as in, alongside the binary], and ofc the weird license situation.

Some more problems on top:

• it's always multiple chromium versions behind, delaying features and bug/security fixes (tbf security fixes get backported). And yes this is somewhat of a problem with webkit too.
• it would result in bigger app sizes
• chromium is not necessarily faster than webkit in general

Honestly as i see it, qtwebengine is the most unlikely addition.

[traverseda]

Can I ask what's weird about the licensing? It seems to be LGPL these days, would that not work for this project?

[FabianLars]

Well, since we'd need more than just qtwebengine alone, we'd probably hit another of the 20 different licenses 😅
But the actual issue here is the commercial dual licensing stuff, which imho is an absolute showstopper for us.

[traverseda]

we'd probably hit another of the 20 different licenses

It's almost all LGPL except for a few libraries that are regular GPL. None of the GPL libraries are things you'd use.

the actual issue here is the commercial dual licensing stuff,

I don't understand why the library optionally being available under a commercial license would be a problem for you? For Tauri everything you'd use is available under the exact same licenses as GTK,

The rust bindings being pretty bad is definitely a problem though.

[FabianLars]

Sorry, forgot to answer.

Just so we're on the same page again, the license is not some kind of blocker, it's just a small additional annoyance, a cherry on top :)
And it's really only a thing because of the bad perception of it because of its history.

This is only a "problem" because we'd be the first contact people would ask questions and complain to (no matter the docs etc), kinda pessimistic i guess, but we get blamed for the weirdest stuff, sorry for the rant.

Edit: And yes i know that i said it's a showstopper above, but that was over-exaggerated(?), because of a) the thing mentioned in the "rant" (i just had a similar issue shortly before that) and more importantly b) i misunderstood things about the license model, sorry about that. But tbf that's kindaaa in favor of my argument, since i did look into it and still got stuff mixed up...

really having trouble finding the right words here 😅 anyway, moving on...

The rust bindings being pretty bad is definitely a problem though.

They are not only pretty bad, they are non-existent for qtwebengine so we'd have to extend existing projects or create something from scratch. And imho it's not worth it at all, if even realistically possible.
Also i don't wanna talk badly about the projects or their maintainers, it's really not their fault that qt is super hard to create bindings for :(

All that negativity aside, if someone has experience with rust+qt and wants to make this work then feel free to reach out to us!

[traverseda]

All that negativity aside, if someone has experience with rust+qt and wants to make this work then feel free to reach out to us!

That's really the main thing. In a lot of projects pull requests aren't really welcome, so seeing that is a big positive. Hopefully there is someone with experience with the rust-qt ecosystem who will be able to take a look, or maybe the QT bindings will get better in the future.

[meisme-dev]

To be clear, I am not suggesting to bundle QtWebEngine with Tauri, as it already comes preinstalled on many systems. I am only suggesting to give the possibility to use it instead of Webkit2GTK.

[FabianLars]

Doesn't really change much to be honest. The main issue (and by far the biggest one) is making tauri use it. Bundling it inside the appimage (as required by the appimage concept) would be just a somewhat big inconvenience on top.

as it already comes preinstalled on many systems

Also this is not reallyyy true, at least in comparison to webkitgtk, but doesn't matter, even if it would be extremely popular we'd still have to act like nobody has it, just to be sure 🤷

[FabianLars]

But on the top of bundling qtwebengine another funny thing caused by the whole "you need to build the app on the oldest system you want to support" thingy: the appimage version would end up using chromium v56 (or v69 if you reduce your target audience).
At least when using the system libraries when building; no idea if there's a way to bundle newer qt versions than your build systems ships with/supports; i'm mainly basing that on the webkitgtk situation...

[amrbashir]

Adding support for QTWebEngine needs a lot of work and time and I think we should invest that into the servo research (Making servo as a webview provider for Tauri on all platforms).