Replies: 1 comment 2 replies
-
|
I want to add WPE port for a long time, but there are still a few blockers need to resolve. The problem first is we cannot really use cog. Last time, we tried to use existing GUI lib the webview library suggests (which is GTK), we have to write every single wrapper in So if anyone is interested in this port, these are two key steps need to be done imho:
|
Beta Was this translation helpful? Give feedback.
-
|
I experimented on my side, and found someone who did experiment on their side as well. It's a lot harder than I expected. The gir generator requires setting up sys crate for all dependencies as well, otherwise it doesn't know what to do with types taken from dependencies. The generation of gir files is the easy part actually… But I'm committed to at least get something on screen… I think a WPE-based webview could unlock currently impossible use cases (eg: embedding the webview in a cross-plateform way) The end goal is to completely replace For the WPE crate, I think I'll only require a |
Beta Was this translation helpful? Give feedback.
-
|
Yes, one of my initial goal to use WPE is to get rid of GTK. In rust ecosystem, almost all frameworks use If you already have gir files, you can get started by reading gtk-rs's gir tutorial. This should help you create the sys crate. But I have not idea what's WPE's dependencies without libraries from GTK. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
The current version of
wry, for linux support, depends onwebkit2gtk, which depends ongtk, which is a whole windowing toolkit.Contrast this to the
wryplatform-specific implementation for Windows and MacOS, which are little more than a thin layer on top of the existing provided system webviews.While this setup may seem satisfactory right now, it has a major limitation. Namely
raw-window-handle. The Windows and MacOS implementations are thin layers, this means it's actually trivial to modify them to accept/use aRawWindowHandlefrom theraw-window-handlecrate, and enable interoperability with other projects such aswgpu.I'm not sure there is a way to get aedit: I have been made aware of gdkx11RawWindowHandlefor a GTK window, or creating a GTK window from aRawWindowHandle.This means you can't use
wryto embed the webview in other applications, which is the primary use case for webviews.Enter WPE
So let's just drop linux support? (:smiling_face_with_tear: Linux user here)
Well, maybe we could find a different webview implementation for Linux. Why is it that we are limited to webkit2gtk? We aren't in fact! The developers of webkit2gtk also develop a version of webkit aimed at embedded systems, it is WPE Webkit. Now I hear you say "we target desktop, can't do with embedded solutions". But in actuality, WPE Webkit does itself only depend on standard linux desktop components.
Nothing easier than using WPE. In fact Igalia provides cog, a way to locally trial wpewebkit: https://github.com/Igalia/cog
I've managed to run WPE locally on my X11 machine fairly easily. And cog exposes (and accepts) the X11 window handles necessary to properly handle
RawWindowHandle.WPE is actually supposed to run on wayland compositors, so we also get wayland support for this.
Downsides:
I've had a very short glance at the cog source and it seems really nice.
Beta Was this translation helpful? Give feedback.
All reactions