Opened 7 weeks ago

Last modified 107 minutes ago

#60511 assigned enhancement

move to quartz as default backend

Reported by: ra1nb0w Owned by: dbevans (David B. Evans)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: ryandesign (Ryan Schmidt), michaelld (Michael Dickens), danchr (Dan Villiom Podlaski Christiansen), rseichter (Ralph Seichter), ctreleaven (Craig Treleaven)
Port: R Togl VLC VLC2 avahi cairo cairo-devel cairomm cherrytree clutter cogl gWakeOnLAN gconf gegl gegl-0.3 gegl-devel geoclue2 glade glib2 glib2-devel glibmm gnome-themes-extra gnubg gnucash-docs gtk-sharp2 gtk2 gtk3 gtkextra3 gtkimageview gtkmm gtkmm3 gtkspell2 inkscape inkscape-devel inkscape-gtk3-devel lablgtk2 libVLC libVLC2 librsvg meld netgen opencolorio pan2 pango pango-devel pangomm pdfpc pidgin pspp pspp-devel py-cairo py-gobject py-pygtk reinteract tix tk tkdnd tkimg tktable ufraw webkit2-gtk webkit2-gtk-devel wxgtk-3.0

Description

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.

Change History (21)

comment:1 Changed 7 weeks ago by 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 ...

comment:2 Changed 7 weeks ago by michaelld (Michael Dickens)

Cc: michaelld added

comment:3 Changed 7 weeks ago by 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.

Last edited 7 weeks ago by kencu (Ken) (previous) (diff)

comment:4 Changed 7 weeks ago by ryandesign (Ryan 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.

comment:5 Changed 5 weeks ago by 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?

comment:6 Changed 5 weeks ago by 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.

comment:7 Changed 5 weeks ago by kencu (Ken)

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

Last edited 5 weeks ago by kencu (Ken) (previous) (diff)

comment:8 in reply to:  5 Changed 5 weeks ago by ryandesign (Ryan Schmidt)

Port: R Togl VLC VLC2 avahi cairo-devel cairomm cherrytree clutter cogl gWakeOnLAN gconf gegl gegl-0.3 gegl-devel geoclue2 glade glib2 glib2-devel glibmm gnome-themes-extra gnubg gnucash-docs gtk-sharp2 gtk2 gtkextra3 gtkimageview gtkmm gtkmm3 gtkspell2 inkscape inkscape-devel inkscape-gtk3-devel lablgtk2 libVLC libVLC2 librsvg meld netgen opencolorio pan2 pango-devel pangomm pdfpc pidgin pspp pspp-devel py-cairo py-gobject py-pygtk reinteract tix tk tkdnd tkimg tktable ufraw webkit2-gtk webkit2-gtk-devel wxgtk-3.0 added
Summary: gtk3, pango and cairo: move to quartz as default backendmove to quartz as default backend

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.

comment:9 Changed 5 weeks ago by 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!

comment:10 Changed 5 weeks ago by 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.

Last edited 5 weeks ago by kencu (Ken) (previous) (diff)

comment:11 Changed 5 weeks ago by ryandesign (Ryan Schmidt)

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

comment:12 Changed 4 weeks ago by danchr (Dan Villiom Podlaski Christiansen)

Cc: danchr added

comment:13 Changed 4 weeks ago by rseichter (Ralph Seichter)

Cc: rseichter added

comment:14 Changed 4 weeks ago by 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 <https://trac.macports.org/ticket/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.

Last edited 4 weeks ago by kencu (Ken) (previous) (diff)

comment:15 Changed 4 weeks ago by 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 :>

comment:16 Changed 4 weeks ago by 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?

comment:17 Changed 4 weeks ago by danchr (Dan Villiom Podlaski Christiansen)

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

comment:18 Changed 4 weeks ago by ryandesign (Ryan 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.

comment:19 Changed 4 weeks ago by 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"

Last edited 3 weeks ago by kencu (Ken) (previous) (diff)

comment:20 Changed 3 weeks ago by kencu (Ken)

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

Last edited 3 weeks ago by kencu (Ken) (previous) (diff)

comment:21 Changed 107 minutes ago by ctreleaven (Craig Treleaven)

Cc: ctreleaven added
Note: See TracTickets for help on using tickets.