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@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-users > _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
