move to quartz as default backend

[ra1nb0w]

What do you think to make quartz the default backend for gtk3, pango and cairo? At least for the 3-4 latest versions of macOS. I am using it from many years and it seems to work quite well with many applications (inkscape and gimp official distribution are using that). Note gtk2 requires pango and it should remain to x11 (at least to me, it works fine with quartz except for gEDA) therefore we should manage the different bakend.

ps. this idea born during the process of updating GNURadio to the 3.8 version.

[michaelld (Michael Dickens)]

I like this idea, as it reduces a set of dependencies for GTK3 (etc). Progress has been made on these ports to make them work with Quartz even better than their predecessors (GTK2 etc) ... so why not embrace this usage of them?

Of course, any port that uses GTK3 (etc) that -requires- Quartz or X11 must do a variant check. Those that can go either way could add variants to do the checking. Or, they can just use GTK3 (etc) as they are installed. There are options ...

[kencu (Ken)]

there were a couple of important gtk3 ports that previously would not build +quartz, which is why I gave up on +quartz...have to see if I can find those tickets. quartz is certainly much nicer, if it covers off enough of the needed ports, to be sure.

[ryandesign (Ryan Carsten Schmidt)]

It's always been recommended that a user make the decision about whether to use x11 or quartz before installing any ports. If they want to change their mind, we recommend uninstalling all ports. If we are proposing to change the default, we would have to do so in all ports that have them, not just the few proposed here. (There are over a hundred ports with such variants.) We also don't have a mechanism that could be used to assist all existing users in upgrading properly. For example, all existing users who are using +x11 and want to continue doing so should add +x11 to their variants.conf, but we don't have a way of notifying users that they should do this, short of the MacPorts release notes and mailing lists and so forth.

Ports that build themselves differently depending on whether a dependency was installed with +quartz or +x11 must themselves have +quartz and +x11 variants. As far as I know we largely do have that already but there could be some that have been overlooked (and that is why we make the uninstall-and-reinstall recommendation). If we switch defaults, that will surely bring such problems to light so that we can fix them.

I was planning on trying out defaulting to +quartz on my system when I upgrade to Catalina since I'll have to reinstall everything then anyway. But I haven't really tried it yet so I can't say how well +quartz currently works generally.

Changing the default for only some OS versions seems like it would cause confusion. It also has the potential to cause problems during migration if the user is migrating between two OS versions for which we've chosen different defaults.

[ra1nb0w]

Sorry for the delay.

Sure, the ports that I listed are only the root and others must be aligned. I noticed that the generic user doesn't know too much about variants and it generally use the default. I have not idea on how to implement this change since I am using +quartz in variants.conf from the benining; I tought that a good opportunity was OS upgrade but you have rejected this idea. Anyway, my experience was fairly positive and the only software that doesn't work well is gEDA that uses gtk2 (probably it doesn't receive too much attention). kencu, have you found the tickets?

[kencu (Ken)]

I didn't go lookingv; my recollection is stumbling over a number of ports that don't build +quatrz

We should not do this without approval from Dave, who is certain to feel strongly about it and has years of insight.

[kencu (Ken)]

I see this is Dave's ticket to own, and he's not commented yet...

[ryandesign (Ryan Carsten Schmidt)]

Replying to ra1nb0w:

Sure, the ports that I listed are only the root and others must be aligned.

Ok so your suggestion applies to all ports that offer +x11 and +quartz variants, not just gtk3 pango and cairo.

I noticed that the generic user doesn't know too much about variants and it generally use the default.

You're probably right. And it would be nice to give users the "best" configuration out of the box. It might be that these days +quartz would give users a better experience than +x11 but I can't personally verify that having not used +quartz.

I have not idea on how to implement this change since I am using +quartz in variants.conf from the benining; I tought that a good opportunity was OS upgrade but you have rejected this idea.

We don't have a mechanism to get people who already had port installed with +x11 to upgrade to +quartz, so that makes changing the default for existing users difficult.

You're right that we could change the default for the next OS version, for example default to +quartz on macOS 10.16 and later and +x11 otherwise. But it feels confusing to me. It would also greatly complicate ports. Currently ports that have these variants write:

if {![variant_isset quartz]} {
    default_variants +x11
}

If we do as you suggest and change the default to +quartz on macOS 10.16 and later then ports that have these variants would have to change that to:

if {${os.platform} eq "darwin" && ${os.major} >= 20} {
    if {![variant_isset x11]} {
        default_variants +quartz
    }
} else {
    if {![variant_isset quartz]} {
        default_variants +x11
    }
}

which is significantly more wordy. There's potential for portfile developers to forget to do this or to get it wrong. We could put this into Yet Another Portgroup that those ports could include instead.

---

One way we could get all users to upgrade to quartz would be to remove the x11 and quartz variants from all the ports and just make then unconditionally use quartz and increase their revisions. But I'm not sure if we're ready to abandon x11 entirely like that.

[kencu (Ken)]

a short browse through the tickets brings up a number of ports that don't build without +x11; I started to list them all for you, but stopped after half a dozen or so. Some unimportant, but I recall there were one or two key ones in particular that a lot of others depended on that would not build +quartz. I remember spending a day trying to fix it two years ago, but too complicated, so I gave up and went back to +x11.

Dave might fill in the names so you can give them a go -- or maybe some kind soul has fixed them in the meantime!

[kencu (Ken)]

homebrew has enabled only quartz on gtk3...fyi. so they make that work...and leave out any formulae that don't work without quartz, I suppose.

[ryandesign (Ryan Carsten Schmidt)]

Some ports that build with tk +x11 but not with tk +quartz are mentioned in this commit message.

[kencu (Ken)]

I set up one of my systems +quartz and started to run a build of gnome. It wasn't long before the errors started coming.

gedit is broken, but looks fixable.

Here's one of the big ones that had a lot of ports relying on it that won't build quartz -- yelp <#55345> I tried (as outlined), also another quite knowledgeable user tried and failed.

And if we ever did get yelp to build and work, we'd only then be able to see what comes next.

[kencu (Ken)]

And then there's this <​https://gitlab.gnome.org/GNOME/glib/-/issues/1263>, where Ionic and Ryan were involved.

I think it was right about that point that I abandoned +quartz, and learned to embrace +x11 :>

[danchr (Dan Villiom Podlaski Christiansen)]

I, for one, welcome our new Quartz overlords!

One a slightly more serious note, I've had -x11 +no_x11 +quartz in my variants.conf for some time. The main annoyance is having to rebuild ports such as GTK+ from source on occasion, but that's the only issue I've run into. To me, ports that use X11 are mostly broken anyway; X11 on OS X was always a stopgap measure to me.

I do get that this is a complicated change, and that there's a lot of infrastructure involved, but that shouldn't distract from the end goal. Here's a suggestion: Would it be possible to treat this like the Qt ports, and move the Quartz and X11 variants into separate ports? That way, any port that requires X11 can safely depend on it, and the upgrade step becomes much more straightforward, doesn't it?

[danchr (Dan Villiom Podlaski Christiansen)]

Just wondering, but what's the reason for not having the GTK+ port depend on X11?

[ryandesign (Ryan Carsten Schmidt)]

For all the libraries that can be built in either X11 or Quartz flavor but not both, we currently have variants. Moving that to subports does seem like it would help this transition because then it would be possible to have both X11 and Quartz versions installed at the same time and the ports for apps that use those libraries could transition from one to the other on their own timetable. This would be a lot of work, because each of those library ports would need to modify its build process to install to different locations, and each of the ports using each of those library ports would need to be modified to find those libraries in those new locations.

The x11 variants of gtk2 and gtk3 do already depend on the needed X11 libraries. They don't depend on xorg-server because they don't require it. They require an X11 server, but that could be from the xorg-server port, or a manually-installed Xquartz, or Apple's X11 app on old versions of Mac OS X, or even theoretically a server running on a different computer. There are many other ports that we handle in this way. For example phpmyadmin is used to administer a MySQL server, but it does not depend on a mysql*-server port because it does not require the MySQL server to be one provided by MacPorts or even one running on the same machine.

There has been discussion elsewhere about wanting to make it easier for users to use software that needs an X11 server. That's a great goal but let's make sure we do it correctly and in a way that works for all ports, not just individual ones. One proposal was to add a dependency on xorg-server despite the fact that that's not strictly speaking required. If we do that, we need to decide what port to do it in. Just gtk2 and gtk3 because they're central libraries? Does that cover all the bases? Or do we do it in the port of every end user app that ultimately displays an X11 interface to the user? A different proposal is to add notes that tell the user to install an X11 server. Again the question would be where to add the notes. Whichever solution is used, we want to avoid telling the user to install an X11 server (or doing it for them) when they really don't need it, for example when they're using the quartz variant. If we're printing notes, we might also want to avoid telling them to install it if they've already installed it. And we want to avoid having to insert a lot of code into a lot of portfiles. If it ends up being a lot of code to get it right, maybe it should be in a portgroup that ports include.

[kencu (Ken)]

So far, no happiness with gedit, and not sure how many others after that. I'm going back to x11 as I find it very functional for me, and everything works there -- although I recognize that a selection of applications do build +quartz, and for some gtk bundlers, that might work out quite well indeed.

This line from upstream was telling:

"the developers who want to specialize their Gtk apps for non-Linux OSes are few and far between"

[kencu (Ken)]

Well, I fixed gedit for quartz, but yelp still doesn't build when quartz is active.

[chrstphrchvz (Christopher Chavez)]

Another example: xcircuit requires tk +x11 (see #37203).

It looks as if this ticket was opened regarding Gtk ports, and not necessarily Tcl/Tk ports; is changing the default for one group not possible without affecting the other group? Otherwise, I wonder if there would be interest in making +quartz default for Gtk ports, but leave tk +x11 the default for Tcl/Tk ports.

(To my knowledge it is not possible to make Tk for X11 and Aqua coexist for a single Tcl installation, as existing programs merely ask for Tk to be loaded, and don't choose which one to use.)

[jjstickel (Jonathan Stickel)]

Anything new for the black screen problem for ​inkscape +quartz? Is it working on Catalina or Big Sur? I gave up on +quartz because of this issue.

[mascguy (Christopher Nielsen)]

Replying to jjstickel:

Anything new for the black screen problem for ​inkscape +quartz? Is it working on Catalina or Big Sur? I gave up on +quartz because of this issue.

I'll look at this as part of the Inkscape update (issue:61404). Hopefully it will be fixed with upstream's latest release, but if not, the fixes/updates in this PR may also resolve it:

​https://github.com/macports/macports-ports/pull/11772

[mascguy (Christopher Nielsen)]

I'm in the process of reworking everything related to all of this - with the ultimate goal of having segregated, non-conflicting subports for X11 and Quartz - so taking over this ticket.

[cooljeanius (Eric Gallager)]

The big blocker for me here would be getting gnome-settings-daemon to work with quartz; that would allow a lot of the things that depend on it to work, too. See also bug #42558 for more info.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

#49376 has been marked as a duplicate of this ticket.

[chrstphrchvz (Christopher Chavez)]

In a2db06e842e283f8949a320697c08f54e4d40662/macports-ports (master):

inkscape-gtk3-devel: remove obsolete port

See: #60511

[mascguy (Christopher Nielsen)]

Pruned the port list, to remove both obsolete ports, as well as xxx-devel variations. (The latter are redundant, and implied by their non-devel counterparts being included.)