Wow. The previous release was in 2016, so I was sure that XQuartz was dead for good. Nice to be pleasantly surprised!
I occasionally use XQuartz to run graphical programs over SSH using X forwarding, although I’ve mostly moved on to other approaches due to a combination of:
1. Bad support for HiDPI displays (theoretically fixable in XQuartz - curious if they will tackle it now).
2. Annoyingly high input and redisplay latency (probably not fixable, just an inherent property of the very chatty X protocol).
> Annoyingly high input and redisplay latency (probably not fixable, just an inherent property of the very chatty X protocol).
Unless there's a program specific to your environment that is causing this, I would say that this is partially fixable. There's some kind of bug/weird implementation detail in the macOS vsync driver that causes massive lag in XQuartz.app and macports' X11.app.
Not sure how XQuartz works, but Apple does like to deprecate APIs when a new one comes out. So if XQuartz relied on any deprecated ones, that would be an issue when they get removed.
hm, I'm using X11 forwarding when I'm on my mac box to control my music player and there is pretty much no latency (and text isn't a blurry mess like rdp / vnc but crisp and sharp). I'm on a gigabit network though.
X11 was designed at a time when local networks carried only a few megabits per second. But apps back then didn't depend on sending lots of bitmaps over the wire, just mostly drawing primitives.
Depends on the program! - I've never minded using Emacs that way, even just over wifi, but a lot of more modern stuff is basically unusable. (I assume these programs draw everything to a local buffer, and then copy that to the screen. Probably fine locally, and I'm sure you do get more control, but it's a lot of data to go over a network!)
Local network of VPN? My first attempt at running IntelliJ across VPN last year was using XQuartz and it worked, but latency was terrible and when changing connectivity it would die. Using VNC allowed the process to keep running in the server session over periods of weeks.
> Older builds required either a lot of hand-holding or Apple
Internal tools, so this will hopefully be a step towards making it easier for
others to drive future releases of XQuartz. If that is something you'd be
interested in, please let me know.
Sounds like they are planning on having the community take over responsibility for XQuartz. Nonetheless it’s great that they put in the work of bringing native Apple Silicon support and making a build system for it that others can use.
Anyways I personally much more rarely need XQuartz now than before, but it’s good to have it be available still if and when you need it.
> Sounds like they are planning on having the community take over responsibility for XQuartz.
Either that, or they realised that it would be literally impossible to build it on Apple Silicon, if the hand holding became not possible and the internal tools not available.
The community took over responsibility for XQuartz almost a decade ago. The build / release process that relied on some internal tooling, which meant only I could do it (until I finally spent a couple days writing a new release script over the Winter holiday).
Awesome. Something about this post really hits home about the amazing people working quietly behind the scenes chipping away to keep everything running.
And then Tom Lane is the first person to weigh in to give thanks?! How do these people manage the breadth of contribution that they do?
A surprising number of features exist in OSX to make it comfortable for people used to Unix-like OSes. It's a shame Apple is so poorly behaved, I'd think about buying a personal mac if it weren't for that.
Their terminal app will simulate a selection buffer for you (although it doesn't integrate with other apps which is why I end up pasting garbage into my terminal almost every time I clone something from github) and can optionally simulate pointer style focus like many X11 window managers do.
Every text widget in Cocoa seems to use Emacs-style GNU readline shortcuts. Something I didn't notice until recently.
Xquartz isn't dead, and interestingly Xlib has outlasted quickdraw and carbon, their own drawing APIs.
There are clearly a couple of people who really care about this internally and push to let it keep these features. I hope that the day when they are drowned out by the rest of the company does not come…
Question: running GTK apps in a Linux VM under Parallels in “coherence mode” provides a better user-experience (in several ways: smoother, better accessibility, etc.) than running a native-macOS-compiled GTK apps under XQuartz does. Why is this?
• Is it a difference of display model? Where/when compositing is done? Is X11 really that high-overhead of a protocol, that putting a “compositor in your compositor” like Parallels’ video driver does, can do better?
• Is it that macOS GTK apps are relying on macOS as the window manager / window decorator (which those apps were never heavily tested for), while “coherence mode” GTK apps are bringing their own DE (GNOME or what-have-you) along with them onto the macOS desktop, which “knows” what to do with those apps much better?
I wouldn't discount the extent to which a Linux distro might tweak some config files and optional dependencies.
An example: when I started using freebsd on a laptop the fonts were pretty crappy relative to Linux. The code for Xorg, freetype etc. were identical in both places. I spent some time editing config files and it looked decent again. I assume my debian setup just had better defaults.
Correct, I've been recommending folks use MacPorts to build xorg-server if they want to stay up to date as I was not able to put out new XQuartz releases for a while. Right now, there are a few bug fixes in the latest XQuartz release which I haven't pulled back into MacPorts yet, but I'll do that at some point soon.
Quartz Composer is a graph of filers that you can interconnect in a graphical interface. You use it to create visual filters or generators. iTunes was using Quartz composer files .qtz for some of his music visualizers.
Quartz Composer is GPU accelerated thanks to its use of the Quartz API.
It was very popular with artists because of the creative freedom it gave when composing the filters. You did not need to be a developer to create a filter, thanks to the editing application.
Quartz Composer is now deprecated and dying in slow and anonymous death.
XQuartz is a windowing system accelerated with Quartz. The X system was not invented by Apple but very popular on top of Unix.
There’s no official commitment to support it but if an Apple Engineering Manager is spending a month updating it I would guess they want to keep it alive for now.
But I thought X was dead? Every day or two I read about how X is dead here, on Slashdot, Twitter, on Michael Larabel's site, everybody chanting it in unison. How could all these voices be wrong? X11 is ALIVE?
I occasionally use XQuartz to run graphical programs over SSH using X forwarding, although I’ve mostly moved on to other approaches due to a combination of:
1. Bad support for HiDPI displays (theoretically fixable in XQuartz - curious if they will tackle it now).
2. Annoyingly high input and redisplay latency (probably not fixable, just an inherent property of the very chatty X protocol).
Still nice to have the option.