webkit2gtk-4.1 has been added to the GNOME SDK. This is the same as the older webkit2gtk-4.0 API, except it is built against libsoup 3 instead of libsoup 2, so it supports HTTP/2.
webkit2gtk-4.0 is now deprecated and will probably be removed in the GNOME 42 runtime. (We’ll ship both WebKits for GNOME 41.) If your application depends on libsoup 2, now is the time to migrate. Please note that libsoup 2 and libsoup 3 may not be used in the same process, so if your application depends on any libraries that use libsoup 2, they’ll need to be ported first before you can upgrade.
If you’re not able to port to webkit2gtk-4.1 before webkit2gtk-4.0 is removed, you can of course build it yourself in your flatpak manifest.
Great! I was not able to compile webkitgtk2 in the last 4 months from source with GTK4 enabled, I think error was indeed related to libsoup. So I was not able to test the gintro Nim bindings for webkitgtk2. My Gentoo-Linux ships GTK4 since approx 6 months now, but without enabling GTK4 for webkitgtk2.
So I hope that I will be able to compile webkitgtk2 from git source now – an when that works I will tell Gentoo people to ship webkitgtk2 with enabled GTK4.
Yet @mcatanzaro isn’t running around screaming that epiphany is broken. This either means that this is fine or that it’ll only break under specific conditions.
Either way, I think it’s better to disable the tracker3 search back end in the runtimes. Thoughts?
My guess is that epi is fine because it doesn’t use GtkFileChooserDialog, so the tracker code in GTK isn’t exercised.
I’m less lucky in Polari, where my attempt to port to soup3 results in an error when trying to re-register the SoupSession type (Polari doesn’t use GtkFileChooserDialog either, so I suspect that this is related to introspection).
As far as I can see, disabling tracker only affects apps that don’t use the portal for opening/saving files. Hopefully there aren’t too many of those, and those that exist could use a little nudge to switch to GtkFileChooserNative IMHO
Ah I didn’t read it as snarky, no worries. You’re just pointing out a problem, after all.
Presumably if tracker were to actually attempt to use libsoup2 at runtime, it would probably explode. Regardless, it’s currently running on undefined behavior, which is not great.
I agree. We can’t immediately port it to libsoup 3, because we have GTK apps that depend on libsoup 2 which are not yet ported. And we don’t have an easy way to parallel install multiple versions of GTK 3. So this seems practical.
Probably a good guess. Since it’s a flatpak app, it uses the file chooser via the file chooser portal. I wonder if non-flatpak builds might be broken.
Alas.
This is a good point. Flatpak apps won’t notice the difference. That said, our GTK is also used by GNOME OS, so we don’t want to disable tracker search permanently. And polari is packaged by Linux distros, and we surely don’t want to port to libsoup 3 if it would break distros. So just solving this in the flatpak runtime is not enough.
Hm, I wonder if perhaps the attempt to migrate one app at a time has just outright failed. We might need a really big flag date like “in GNOME 41 and Fedora 35 everything uses libsoup 2, in GNOME 42 and Fedora 36 everything uses libsoup 3, anything not ready gets left behind.” @pgriffis@carlosgc?
That said, our GTK is also used by GNOME OS, so we don’t want to disable tracker search permanently.
Mmh, right. I guess we don’t want to use different build configurations for GNOME OS and the runtime?
(Asking to get a clearer idea how to go forward with the port in Polari. A soup-less GTK3 in the nightly runtime would be the most convenient, but I can also add my own gtk build temporarily to test that a soup3option actually works)
It doesn’t, because we only have one build of GTK 3 and tracker. To port GTK 3 apps to libsoup3 without a flag date, we would need both tracker and GTK 3 to grow a second parallel-installable build that uses libsoup 3.
The flag date seems like the only reasonable approach IMO.
IMO yes, because nothing can safely use it without accidentally linking to libsoup 2. Either everything using GTK and WebKitGTK must be ported, or nothing must be ported.
The API split between webkit2gtk-4.0 and webkit2gtk-4.1 may have been a mistake. The goal was to allow parallel-installability, but this didn’t account for the fact that GTK 3 itself depends on libsoup via tracker, but neither GTK 3 nor tracker has parallel-installable libsoup API variants.
It’s not a very long wait. gnome-build-meta will branch gnome-41 in less than one month, when 41.beta is released. That seems like a good time to switch tracker to libsoup 3. We would want to remove libsoup 3 and its dependencies from GNOME 41 in the meantime, including temporarily removing webkit2gtk-4.1 and switching Epiphany back to libsoup 2. If we want to go a little crazy, we could perhaps branch early, keep master on libsoup 3 (and switch tracker to libsoup 3 there), and revert all the libsoup 3 stuff on the gnome-41 branch now. I wonder what other release managers think about this?
Either way, modules are going to temporarily require build options so that we can manually decide which version of WebKitGTK and libsoup to build against.
I think it would be fine to include libsoup3 as a technology preview in 41, but build tracker and webkit against libsoup 2.
I wouldn’t branch early. Even when branching for beta we find ourselves backporting stuff. And there is also the rush to add things just before the freeze that I think it doesn’t really make sense to branch early. We could however have a libsoup3 branch and start porting stuff there.
EDIT: we should also announce that soup2 is going to be dropped from the runtime for 42. We probably also want to schedule a release team meeting right before the beta to sort out the stuff that will change in 42 so we announce it properly.
