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.)

[christophecvr (christophecvr)]

I did try to build macports on macbookpro mid 2010 High Sierra (10.13.6) with quartz only. That is only possible for a couple of gnome packages. When You need any gnome package requiring the gnome-desktop or any package coupled to the gnome-core x11 is always required. So if you're goal is to use a lot of gnome packages x11 is a must. It's bad luck that glib2 can not be build for both (native and generic) If this was the case gtk3 could also be build for quartz and x11. I just succeeded in now building today a perfect working totem which is the base core gnome video player. However I needed to build a lot self and reconfigure a lot of base macports packages. The required changes can be seen in . ​https://github.com/christophecvr/macports-ports/tree/cvrwork . The patches comparing the original mac-ports are ​https://github.com/macports/macports-ports/compare/master...christophecvr:macports-ports:cvrwork . Yes first you need to install all avbl codecs also nonfree (so you can't redistribute build packages). Rebuild the full ffmpeg with all codecs this is required later for the package gst-libav who uses the ffmpeg build codecs. Then uninstall gstreamer1-gst-plugins- (all installed ones with -f option) rebuild gstreamer1-gst-plugins-base with x11 and !!! gl support (without gl support the whole gstreamer1 is useless to play a video). See the receipes in my git. Then build the gstreamer1-gst-libav. then good,bad and ugly. Build them all with -s option. I also set compiler to macports-clang-16 . But actually You can now use macports-clang-17.

Before that also glib2,gobject-introspection and gtk3 needs to be rebuild. min required version is 2.80.0 with the current down graded version it does not work. So you need to use my current receipes for glib2,gobject-introspection and gtk3. uninstall glib2,gobject-introspection and gtk3 with -f option. Build glib2 with x11 support (generic) it will be build without introspection first. Then build gobject-introspection. Then build glib2 again with -s and +x11 +introspection variant.

After all this a good working totem player can be build. It does work now without stutters and so and does play dvd iso images.

The mpv-legacy does not work well att all. and mpv 3.8 can't be build on this old macos. So for high sierra x11 is required but build well without universall support. I guess that for mojave 10.14 it will be same. But higher I don't lower the high sierra I don't ( by the way the official given xcode 10.1 does has sdk-10.14 ) All packages do build fine (without universall support) since the high sierra core is full x86_64 universall support is present but not required at all and the given sdk does not support universall.

[christophecvr (christophecvr)]

But with quartz only you can well use vlc player which works with ffmpeg and quartz.

[kencu (Ken)]

a good video player all the way back to Tiger is mplayer, I found.

[mascguy (Christopher Nielsen)]

Replying to christophecvr:

Before that also glib2, gobject-introspection, and gtk3 needs to be rebuild. Min required version is 2.80 with the current downgraded version it does not work.

Just to confirm, are you saying that glib2 and gobject-introspection must be at 2.80/1.80, for your updates to work?

That's very surprising, as glib2 2.80 was released six weeks ago, while gobject-introspection 1.80 was released three weeks ago.

Can you elaborate in terms of which component(s) need the latest releases of these two ports?

[christophecvr (christophecvr)]

Replying to mascguy:

Replying to christophecvr:

Before that also glib2, gobject-introspection, and gtk3 needs to be rebuild. Min required version is 2.80 with the current downgraded version it does not work.

Just to confirm, are you saying that glib2 and gobject-introspection must be at 2.80/1.80, for your updates to work?

That's very surprising, as glib2 2.80 was released six weeks ago, while gobject-introspection 1.80 was released three weeks ago.

Can you elaborate in terms of which component(s) need the latest releases of these two ports?

Yes that was pretty strange issue. Before the initial upgrade to 2.80/1.80 all worked fine. Then we had the upgrade with a couple of missing gir gobjects and a couple off packages did not build anymore. I actually then proceed to install it like you proposed before the downgrade. By first building glib2 without introspection,build introspection and then rebuild glib2 with introspection enabled. It worked perfect after that. After the downgrade back to previous version I tried that also but then i went in to error on error on building. So I changed the ports back to 2.80/1.80 building on the way glib2 no intr. introspection then glib2 with introspection and all runs fine. I really can't explain why it well works perfect so now. (maybe if a completely uninstall all macports build and restart from scratch it probably works again with the previous glib2/and introspection).

About the gstreamer it is just adapted to my needs (concerning codecs due to the gst-libav also ffmpeg needs to be installed with the nonfree codecs). But on High Sierra the build with xcode and gl does work perfect I must well also build the quartz components cause once gl is used there is a macos framework check about installed gl functions and they always include checks for the cocoa functions). But for gstreamer it is not a problem at all since gstreamer does build separate extra packages for quartz and x11. You can check this into /opt/local/lib/pkgconfig. package gstreamer-gl-1.0.pc is for the cocoa and quartz gl. package gstreamer-gl-x11-1.0.pc for the build of x11 gl support. See also extended api manual of gstreamer self. To use the right gl libs is then a task for the application self. To be honest I till now only build one application who uses gstreamer that is totem and totem must have x11 and gstreamer with gl support . I knew the old days that totem was working with xine backend instead of gstreamer but that's long ago and was on the gnome2 and gstreamer was still 0.xx in those days. But now totem does play dvd iso files fine (just at the dvd start menu a little stuttering but once launched it plays perfect now). But totem is not really needed since vlc can be used to also play all video files and dvd's and vlc works even better. mpv-legacy does not work on macos-10.13.6 no sound on videos and dvd menus are showed but you can't select a item.

But as a general remark is x11 really needed. That depends on the packages you want to install. If you need packages that needs the installation of gnome-desktop (such as nautilus for example) yes x11 is required and glib2 gtk3 can only be used with x11 support. If You do not need any of these packages you can build with quartz only in a certain way it is even nicer since you have the use of apple menu's on top of you're desktop. With gedit for example the apple menus is really nice . On the other hand when using x11 the graphics are much sharper then with quartz.

[kencu (Ken)]

my newer systems all use +quartz and the graphics look very sharp to me.

[christophecvr (christophecvr)]

Replying to mascguy:

Replying to christophecvr:

Before that also glib2, gobject-introspection, and gtk3 needs to be rebuild. Min required version is 2.80 with the current downgraded version it does not work.

Just to confirm, are you saying that glib2 and gobject-introspection must be at 2.80/1.80, for your updates to work?

That's very surprising, as glib2 2.80 was released six weeks ago, while gobject-introspection 1.80 was released three weeks ago.

Can you elaborate in terms of which component(s) need the latest releases of these two ports?

p.s. Now as test i'm building full macports from scratch. Cause I first will now do full tests using only quartz. (some applications will not work then). I started now with the introspection from current master 2.78 and 1.78 or so . Then the builds are working back ok.

[christophecvr (christophecvr)]

Replying to kencu:

my newer systems all use +quartz and the graphics look very sharp to me.

Well it is actually gedit which is much sharper with x11 then with quartz.

[kencu (Ken)]

OK, I’ll check gedit again specifically. It looked just fine last I checked, though.

What system are you blurry on? Can you post up a screengrab?

BTW, homebrew builds everything +quartz , so if there is ever any systemic issue they quickly resolve it with upstream.

[christophecvr (christophecvr)]

Well I'm now just rebuilding from scratch without x11. Will see what it gives.

[kencu (Ken)]

gedit +quartz looks beautiful to me (see attached screenshot), however I did need to turn off "use the system fixed width font" in settings to get a clean sharp font.

looks like the default font used by gnome quartz apps might need to be looked at. I forget just right now how that is set.

[kencu (Ken)]

gedit +quartz running on Monterey Intel

[mascguy (Christopher Nielsen)]

Replying to christophecvr:

Replying to kencu:

my newer systems all use +quartz and the graphics look very sharp to me.

Well it is actually gedit which is much sharper with x11 then with quartz.

Typically things are blurry when the user has a high-dpi (aka retina) display, but the app doesn't advertise that it supports it. And indeed, gedit doesn't do that.

So try adding app.retina yes to the portfile, and rebuilding.

While I can't guarantee that will fix it, there's a fairly good likelihood that it will.

[kencu (Ken)]

I most often just launch it from the terminal, which skips all that stuff. I guess I should try the launcher app and see if it works differently that way.

[christophecvr (christophecvr)]

Replying to mascguy:

Replying to christophecvr:

Replying to kencu:

my newer systems all use +quartz and the graphics look very sharp to me.

Well it is actually gedit which is much sharper with x11 then with quartz.

Typically things are blurry when the user has a high-dpi (aka retina) display, but the app doesn't advertise that it supports it. And indeed, gedit doesn't do that.

So try adding app.retina yes to the portfile, and rebuilding.

While I can't guarantee that will fix it, there's a fairly good likelihood that it will.

Just done it and indeed now i'm happy with the quartz version. As font I just changed it to menlo 12 then it is perfect. My displey is a retina one.

[christophecvr (christophecvr)]

The only problem with gtk without x11 is that we can't build nautilus file browser. I could not find any other good replacement. Does someone already tried to make a port for nemo file browser the default cinnamon file browser ?

Sorry found answer no not possible without x11.

[holymonson (Monson Shao)]

FYI, this repo ​https://gitlab.gnome.org/GNOME/gtk-osx, owned by the gnome team, holds version-locks and patches to build MacOS application bundles for Gtk+-based applications. And they builds with +quartz (and higher webkit2-gtk). We may follow their steps cause they have better experience building gtk apps on macos.

[cooljeanius (Eric Gallager)]

Latest problem I've been having on this front has been #70274