cairo +quartz pango +quartz

[vtjnash (Jameson Nash)]

Since cairo and pango seem perfectly able to install themselves with both cairo and pango support enabled, it seems unnecessary (and in some cases detrimental) to artificially limit the capabilities of the installed code. Instead it seems a better default for these libraries would be:

+quartz +x11

Or to just eliminate these two options altogether.

As mentioned in previous tickets (e.g. comment:ticket:31148:3), in the distant past this was not possible. however, now the existence of these options just seem like an unnecessary annoyance to the user. It feels like this is just a historical artifact: is there a more recent reason that this must still be the case?

(Similarly, the restriction preventing building gtk3 +x11 +quartz seems to be artificial, since the backend can be selected at runtime via environment variable: GDK_BACKEND=quartz ​https://developer.gnome.org/gtk3/stable/gtk-running.html)

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

I would like to do this—remove x11 and quartz variants from pango and cairo and make both backends on all the time—I'm just nervous about this change causing build failures for some other ports. I could make the change on my system and see what happens as I rebuild ports that use pango and cairo.

[larryv (Lawrence Velázquez)]

Replying to ryandesign@…:

I would like to do this—remove x11 and quartz variants from pango and cairo and make both backends on all the time

OMG YES PLEASE FOR THE LOVE OF GOD

[vtjnash (Jameson Nash)]

I can't imagine it being a whole lot worse than the current situation, where you have random ports like gconf which declare x11 conflicts quartz, even though it appears that gconf doesn't actually have any x11 or quartz code.

Since I prefer to configure gtk to use +quartz whenever possible, this leads to countless ports failing needlessly.

[ryandesign (Ryan Carsten Schmidt)]

Many ports that don't actually have any x11 or quartz code nevertheless build themselves differently depending on whether the x11 or quartz variants of their dependencies are selected. That's why those ports also have needed to have x11 or quartz variants. That need would go away for gconf if all of the ports gconf depends on no longer need their x11 and quartz variants. I don't know if that will be the case.

My hesitation in making this change is ports like py-cairo which contain code like this:

    variant x11 {
        require_active_variants path:lib/pkgconfig/cairo.pc:cairo x11 quartz
    }

    if {![catch {set result [active_variants path:lib/pkgconfig/cairo.pc:cairo x11 quartz]}]} {
        if {$result} {
            default_variants +x11
        }
    } else {
        default_variants +x11
    }

This seems wholly wrong, even now, and will be wronger once pango and cairo are changed to no longer have x11 and quartz variants. Sean, how shall we handle this? Do we just remove that code once pango and cairo are changed?

[seanfarley (Sean Farley)]

Replying to ryandesign@…:

Many ports that don't actually have any x11 or quartz code nevertheless build themselves differently depending on whether the x11 or quartz variants of their dependencies are selected. That's why those ports also have needed to have x11 or quartz variants. That need would go away for gconf if all of the ports gconf depends on no longer need their x11 and quartz variants. I don't know if that will be the case.

My hesitation in making this change is ports like py-cairo which contain code like this:

    variant x11 {
        require_active_variants path:lib/pkgconfig/cairo.pc:cairo x11 quartz
    }

    if {![catch {set result [active_variants path:lib/pkgconfig/cairo.pc:cairo x11 quartz]}]} {
        if {$result} {
            default_variants +x11
        }
    } else {
        default_variants +x11
    }

This seems wholly wrong, even now, and will be wronger once pango and cairo are changed to no longer have x11 and quartz variants. Sean, how shall we handle this? Do we just remove that code once pango and cairo are changed?

I must admit that this code block is from my early days in macports. It was copy-n-pasted most likely. It's fine to remove, I think.

[ryandesign (Ryan Carsten Schmidt)]

cairo in r128925, pango in r128926.

I decided to keep the x11 variant, since some users do really want to avoid installing the X11 libraries and would like to disable that variant.

The quartz variant is still there as well, but is always enabled on OS X; I kept it to help out dependent ports that might check whether the variant is selected. I'll probably remove the variant sometime down the road.

[vtjnash (Jameson Nash)]

That sounds like a great solution. Thanks! I think this will make it much easier to avoid dependency issues when installing +quartz libraries.

Are you planning on propagating the change further. For example, for gtk3:

--- ports/gnome/gtk3/Portfile.orig	2014-11-30 11:55:30.000000000 -0500
+++ ports/gnome/gtk3/Portfile	2014-11-30 12:01:04.000000000 -0500
@@ -142,8 +142,9 @@
     configure.args-append --disable-cups
 }
 
-if {![variant_isset quartz]} {
-    default_variants +x11
+default_variants +x11
+platform macosx {
+    default_variants        +quartz
 }
 
 if {[variant_isset universal]} {
@@ -221,14 +222,14 @@
     configure.cc "${configure.cc} ${configure.cc_archflags}"
 }
 
-variant quartz conflicts x11 {
+variant quartz {
     require_active_variants path:lib/pkgconfig/cairo.pc:cairo quartz
     require_active_variants path:lib/pkgconfig/pango.pc:pango quartz
 
     configure.args-append   --enable-quartz-backend
 }
 
-variant x11 conflicts quartz {
+variant x11 {
     require_active_variants path:lib/pkgconfig/cairo.pc:cairo x11
     require_active_variants path:lib/pkgconfig/pango.pc:pango x11

and gconf:

--- ports/gnome/gconf/Portfile.orig	2014-11-30 12:03:50.000000000 -0500
+++ ports/gnome/gconf/Portfile	2014-11-30 12:10:08.000000000 -0500
@@ -70,14 +70,19 @@
                configure.args-delete --without-openldap
 }
 
-variant quartz conflicts x11 {}
-variant x11 conflicts quartz {}
+variant x11 {}
+variant quartz {}
 
-if {![variant_isset quartz]} {
-        require_active_variants gtk3 x11 quartz
-        default_variants +x11
-} else {
-        require_active_variants gtk3 quartz x11
+default_variants +x11
+platform macosx {
+    default_variants +quartz
+}
+
+if {[variant_isset quartz]} {
+    require_active_variants gtk3 quartz
+}
+if {[variant_isset x11]} {
+    require_active_variants gtk3 x11
 }
 
 # The rules enabled by gobject-introspection require GNU make 3.81+

[ryandesign (Ryan Carsten Schmidt)]

I am hoping that the maintainers of those other ports will propagate the changes as appropriate.

[nerdling (Jeremy Lavergne)]

Cc Me!

[RJVB (René Bertin)]

Do any of you who are so much in favour of imposing +quartz even use X11 applications regularly enough to care how fonts render in them?

I do, and have spent quite a bit of time proposing variants to freetype, fontconfig and cairo that leverage bohoomil's variant of Infinality patches with the immense database of rendering configuration files for individual fonts.

With those, text rendering is actually considerably better (I'll avoid the term significant as that would suggest I have a quantitative measure) under X11 than it is under OS X itself.

I've just spent a day trying to figure out why I didn't get this benefit (= text looked so lousy) since migrating to 10.9, while the same freetype,fontconfig,cairo ports on 10.6 gave the expected near perfect quality. On a hunch, I deactivated the latest pango-cairo that had a +quartz variant and activated the previous point release. Apparently that one was built before I built cairo with +quartz ... and all of a sudden the infinality quality was back in its full glory, without changing anything to the cairo build.

I now understand why rendering looked so lousy: most of the functions involved in text rendering simply didn't call the freetype backend, but the quartz one. That also explains why the infinality tweak env. variables had 0 effect. Curiously, those variables do effect rendering in wine applications (I have port:wine-devel) which to my knowledge no longer display through X11. Regardless of what pango-cairo version I have activated.

Looking at the pango-cairo build process I see that it picks up the available cairo backends, and for some reason gives priority to the quartz backend.

Is it possible, at a system-wide or user-wide level, to configure the order of preference in which to use the available cairo backends?

If that's not possible, I'd really have to ask not to remove the option to remove the quartz option, or to replace it with its opposite. I know there's a policy against negative variants, but in this case it might be a way out of what would otherwise be a dilemma. Infinality would become something for people who can follow instructions like:

• build cairo+infinality+x11+noquartz
• (re)build pango-cairo so that it doesn't see the quartz backend during the configure step
• rebuild cairo without +noquartz if required

What does the cairo quartz backend provide that the freetype backend doesn't? Freetype is not itself depend on X11 nor is its use restricted to X11 applications...