gtk2 and gtk3 ports and +x11 vs +quartz variant worries

[David Evans]

On 10/10/16 2:18 PM, Ken Cunningham wrote:
>>
>>
>> These are all legitimate and in my experience tend to come from trying to switch from building +x11 to building +quartz
>> without "cleaning the slate" as it were.  I always do this when switching like this (say with gimp2 that can build
>> either way).
>>
>> sudo port install gimp2 (implied +x11 since it builds with x11 by default)
>> sudo port deactivate active
>> sudo port install gimp2 +quartz
>>
>> This ensures that all the various sub-dependencies get built in the correct flavor.
>>
>> Or install a separate MacPorts instance for building +quartz.  I've successfully done this as well.
>>
>> I run into these issues alot with the GNOME ports because some GNOME ports can build +quartz but not all.  In
>> particular, ports that are part of the GNOME desktop infrastructure (e.g. gnome-desktop, gnome-settings-daemon) still
>> use X11 features directly and thus can't be built +quartz.  Others, like gcr, are just old implementations that use some
>> X11 hack instead of porting to a backend agnostic gtk3 implementation.
>>
>> My general guidelines are this: if there is no +quartz variant, it builds with X11.  This includes ports with no variant
>> at all.  Only ports with +quartz variants should be assumed to build that way.
>>
>> Dave
>>
> 
> Very helpful, thanks Dave.
> 
> It’s true — I had decided to go with +quartz (why not, I thought) but then something I wanted to install required +x11 along the way and I blew things up when I tried to satisfy that dependency.
> 
>  I see there was a similar thread on the dev list that I noticed afterwards. 
> 
> Would there be use for a list or table of gtk ports that are only available in either quartz or x11 variants, but not both, so someone might know going in before they start which way to lean? Perhaps I might work on creating something like that, for my own education if for no other reason.

Yes, that's a good idea.  For some time, I've wanted to put together a database of GNOME ports with this information
as well as various other attributes that can be used to easily generate an ongoing status web page.

However, the issue overall isn't as simple as it seems at first blush.  Issues for GTK2 ports are really not the same as
for gtk3 ports and I can attest that the level of quartz backend support in GTK3/GNOME is not uniform over the range of
ports but is really dependent on the interest level of a ports given developers.  Overall quartz is taking a back seat
to some other alternative backends, particularly wayland as a replacement for X11 on Linux platforms.

Another issue is that of using variants themselves.  variants are not tags but toggles. Giving a port a +x11 variant
implies that -x11 makes sense and not necessarily in the Quartz sense.  There are ports that optionally use/support X11
but can work without it altogether.  It makes sense for them to have an +x11 variant.

But, in my mind, a port that requires X11 and has no alternative to it should not have a +x11 variant. In ports like
this I use require_active_variants liberally to let the user know if an +x11 variant is required in any key dependency.

gnome-desktop and gcr are good examples of this.

Finally, one of the big differences between gtk2 and gtk3 is that in gtk2 you have to build with one backend or the
other.  In gtk3, any and all backends can be built simultaneously (although we don't do it yet).  So think about
what the effect would be if you could build gtk3 +x11 +quartz in a manner similar to cairo and pango.  In this mode,
it would be up to the application to use the appropriate API (which exists in gtk3) to determine available backends and
react appropriately in each case if it makes sense to do so.

Some do now, some do not.

Lots to think about but I'd welcome as a start a list that indicates which GNOME ports can be built +quartz, which could
but are not yet appropriately ported or have been but don't work +quartz (yelp) and which, by their nature, cannot use
Quartz without upstream modifications.  Contact me off list if you (or anyone else for that matter) are interested in
collaborating on such a list.

Thanks, Dave