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

[David Evans]

On 10/11/16 2:17 AM, Russell Jones wrote:
> Interesting. Aren't the main requirement for quartz and wayland support the same, i.e. port to GTK+ 3 and don't use X11
> calls? Or is it more subtle than that?

Well, that's the general idea and anyone writing a new GTK3/GNOME app should think about doing it this way.  This idea
isn't restricted to any specific GTK3 backend but all of them.

The issues that are impact Quartz support that I see are:

 * The popularity of Wayland on Linux platforms (I'm not sure that it's possible to port Wayland to macOs or that you
would want to) hinders Quartz backend development as most of the cycles are going to Wayland and fixing issues in the
Quartz backend doesn't get much attention.  Most recent requests get a "We don't have time/expertise for this but if you
fix it we will consider your changes."

 * On the other hand, the popularity of Wayland helps Quartz (and the other backends as well) by encouraging GTK3
application developers to develop backend agnostic apps as you say.

 * This is well and good for new apps, but many apps (including many of the GNOME 3 ones and most key parts of the GNOME
desktop infrastructure) historically have used X11 directly (via the gdk backend APIs) or even directly to X11 after
obtaining an appropriate native references.  The main culprits here are gnome-desktop (which uses X11 directly and
provides some common desktop APIs that might be used by any GNOME app) and gcr (which provides library support for
security keys and certificates as well as a common widget library and directly uses X11 window ids in one instance).
Both of these apps are thus X11 only and because they provide shared libraries to other apps, those apps are X11 only as
well.  So these ports and any others that are holding on to a historical dependency on X11 are gating items for making
full backend neutrality in GNOME a reality.

 * Finally the overall GNOME project is open source and so they have no way of forcing developers to pay attention to
these issues.  So some apps are doing better because the developers involved are interested in Wayland or Quartz or
whatever and others are not interested at all or don't have any experience to know what to do.

To try and quantify things, here's my first pass at a list of the GTK3/GNOME ports impacted by gnome-desktop and gcr:

gnome-desktop:

eog
epiphany
gnome-characters
gnome-control-center
gnome-flashback
gnome-font-viewer
gnome-panel
gnome-photos
gnome-session
gnome-settings-daemon
gnome-weather
nautilus
totem

gcr:

empathy
epiphany
evolution-data-server
gnome-online-accounts
libgdata
seahorse

Ports included in the current GNOME3 core distribution (gnome3-core) with +quartz variants:

clutter
cogl
evince
gedit
gegl-0.3
gnome-themes-standard
gspell
gtk2
gtk3
gtkmm3
gtksourceview3
librsvg
pango
pangomm
yelp (but still a work in progress and not committed -- builds but crashes on startup)

Ports included in the current GNOME3 apps distribution (gnome3-apps) with +quartz variants:

gitg
glade

As you can see, epiphany, which started this series of threads depends on both gnome-desktop and gcr! No +quartz!!

As usual, I got a little carried away but hope this helps folks understand the issues associated with +quartz -quartz.
I'm working the issue but if anyone would like to jump in and help, let me know.  Experience with both X11 and macOS
internals is, of course, a plus.

Dave


> 
> Russell
> 
> 
> On 11/10/16 02:42, David Evans wrote:
>> Overall quartz is taking a back seat to some other alternative backends, particularly wayland as a replacement for X11
>> on Linux platforms.
> 
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
>