WebKit2-GTK: quartz VS XQuartz

Tue Apr 5 00:06:15 PDT 2016

Thanks Dave, the multi backend seems like the best approach to me.

For what I've seen, the difference between building for gtk3 doesn't
require gtk2 while by default, the X11 targeted webkit2-gtk brings in gtk2.

I'm not sure it's a WebKit issue because like I've said building for gtk3
+quartz works without problems, it looks like something is missing/wrong on
the default build.
However, I will try Epiphany and see how it goes (btw, my primary, default,
platform is GNOME on ArchLinux so I'm sure Web there is OK and everything I
write is tested there first)

I have an old mac mini I use for testing/developing purposes only, it's
intel on El Captain so if it's needed to build or test or verify anything
just ping me and I'll have no problems letting it work. It's just a bit
slow so last time it built WebKit took around 3 days doing only that.

Best Regards

On Tue, Apr 5, 2016 at 12:10 AM, David Evans <devans at macports.org> wrote:

> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20160405/e18c7993/attachment.html>