WebKit2-GTK: quartz VS XQuartz

[Andrea Giammarchi]

answering to James first

> Wayland offers the same disadvantages as quartz ... try to sell you
argument to http://ltsp.org

so, here we are talking about Darwin as the target for GTK3 and WebKit2GTK
via MacPorts.
What should I sell to ltsp exactly I've no idea, also I think is really out
of scope.


Answering to Mojca, I do have a Mac Mini 2010 Dual core 2.4Ghz + 8GB of
RAM. It's not the fastest machine on earth but it works and it's lying
around.
If it has to build 24/7 it's OK but I don't know how to configure it or
what exactly should I do to contribute.


Best Regards






On Mon, May 9, 2016 at 9:00 AM, Mojca Miklavec <mojca at macports.org> wrote:

> On 8 May 2016 at 11:19, Andrea Giammarchi wrote:
> > Like I've said, telling users they need to wait at least one hour to
> > install and build gtk3 +quartz and webkit2-gtk +quartz due lack of pre
> built
> > version
>
> There are two options:
> (i) Switch the default from x11 to quartz
> (ii) Provide binaries for both x11 and quartz
>
> The first option is problematic because a lot of software doesn't work
> without X11 (assuming that GTK implies X11). If MacPorts switches to
> Quartz, all that software will be broken and it would be even more
> pain to explain to users that they need to switch to X11 just to get
> the software from a broken state to a working state (and they would
> also have to compile equally long). Now only those who want a better
> user experience have to switch.
>
> In theory there is also:
> (iii) allow co-existing support for quartz and x11 (at least for gtk3;
> I'm sure this is not possible for wxWidgets for example)
>
> So at the moment we could consider different options for (ii). These
> are for example:
>
> (a) Provide support for resolving dependencies automatically (some
> work has been done during GSOC 2015, but it has not been finished
> yet). Then the required binary packages would be built automatically
> on the buildbot (as soon as one package would request "gtk3 +quartz").
>
> (b) Provide more hardware to set up a separate buildbot with "+quartz"
> being set by default. This means 6 additional virtual machines running
> on Apple hardware. That's not trivial, at least not at the moment.
> (Does anyone have extra hardware lying around? It has to be reasonably
> fast to catch up with all commits though. If so, we could in principle
> play with an unofficial buildslave building packages for +quartz.)
>
> (c) Modify the existing buildbot setup to perform (very) dirty tricks
> to build support for +quartz (for example: build packages, deactivate
> them, modify the default variants to add +quartz, build packages
> again, deactivate them, set the default flags back).
>
> It's also true that if binary packages for Quartz were supported,
> there would probably be more incentive to fix the broken software.
>
>
> But unless you have concrete solutions for any of the points mentioned
> above ...
>
> Mojca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20160509/3a5ddeec/attachment.html>