WebKit2-GTK: quartz VS XQuartz

[David Evans]

On 4/4/16 1:21 AM, Andrea Giammarchi wrote:
> Some sort of followup from mozjs24 thread, strictly related to WebKit2 GTK3.
> 
> The default, XQuartz based version, seems to have some issue with SSL / HTTPS sites.
> 
> If you use this file as example:
> https://github.com/WebReflection/jsgtk/blob/master/examples/browser.gjs
> 
> you'll notice a `broken pipe` error everytime you try to reload `https://www.google.com/` or any other https site.
> However, if you try any non htps site, it will show it without problems.
> 
> Working example:
> `gjs browser.gjs http://archibold.io/`
> 
> Omit the site to try google.com <http://google.com> and its default redirect to https that will break.
> 
> I'm not sure there's a missing dependency or something, all I know is that using the `+quartz` based version doesn't
> have any issue (or at least, not this one).

Have you tried epiphany as your browser?  I haven't tried it for the examples that you mention but it uses WebKit2 via
X11 as well (but not js).  If the issues that you mention persist they should be reported upstream to the Webkit developers.

> 
> However, I've also realized using `-x11 +no_x11 +quartz +gtk3` variants means that **a lot of stuff needs to be built**,
> but I find the quartz based version of GTK3 faster, in terms of bootstrap time, good and same looking of XQuartz,
> through the adwaita icon theme, and also a more consistent experience compared with the one offered by Homebrew.

You're using too many variants and causing some extra rebuilds.  You really only need to use gtk3 +quartz to build the
quartz version.

Specifically:

   +no_x11: this is an old usage that has been largely if not if not completely removed from usage in MacPorts.  Not
required for gtk3 or its dependents. Or anyone, I think.

   -x11: this is not needed either since gtk3's dependents that care (cairo, pango) have, for some time, built with both
+x11+quartz by default.  That is, with both backends enabled.  So the default build is usable with either gtk3 +quartz
or gtk3 +x11.  If you use -x11 you will force a non-default build of cairo +quartz, pango +quartz only.

   +gtk3: this variant is only used by a very small set of ports (gtk3 and its dependents are not included).  Typically
these are gtk2 apps that are in the process of porting to gtk3 but consider the gtk3 version experimental.  A good
example is inkscape.  At any rate, I only count 14 ports that use it as this point.  You can use

port echo variants:gtk3

to see the list.

> 
> As summary, and for the sake of GTK3 users:
> 
>  1. wouldn't be better if MacPorts GTK3 was using by default quartz instead of XQuartz backend? This would solve the
>     problem with not having XQuartz installed

The point of MacPorts is to port open source software to Mac OS X that is usually targeted by default at UNIX/Linux
plaforms.  This largely means X11 (or maybe wayland).  Ports that only support Quartz build natively and so don't need
X11 nor support X11.  At this point, some of the (originally X11) ports will build using quartz but many will not.  Thus
X11 is still the primary display mode for most ports. As has been mentioned elsewhere, GTK+ 3 quartz support is not up
to par with X11 at this point. More involvement by Mac enthusiasts in GTK+ upstream development could help the issue here.

>  2. wouldn't be better macports experience if quartz backend was also pre-built like it is for the xquartz one?
>     Installation time is 10x slower than the Homebrew one

This could probably be done, but would require more buildbot resources than we currently have allocated.  Ryan, our
sysadmin for these issues, could address what it would take to do this.  Note that once you have built both gtk3 +x11
and gtk3 +quartz you can switch from one to the other by deactivating one and activating the other.  This is a matter of
replacing one binary image with another so no compiling is involved and should save you a lot of time if you're not
using it currently.

However, there is another way.  gtk3 has for some time supported the concept of building with multiple backends
simultaneously (as cairo and pango do).  So we could look at having a single gtk3 +quartz+x11 default build.  I'm
looking at what the consequences of this would be on gtk3's dependent ports as a background task at this point, but it
should be doable.  Unfortunately gtk2 does not support this ability and probably never will.
> 
> Last, but not least, is there a way to specify quartz variants at runtime, instead of modifying the
> `/opt/local/etc/macports/variants.conf` file ?

No, because, in general, the differences are resolved at build time using different code paths for each type.  This is
not a MacPorts issue but an issue for the upstream developers of a given app.

Hope this clears up a few issues.

Dave Evans, gtk3 maintainer