make xorg-server a dependency of x11 ports?

[Fred Wright]

On Wed, 20 May 2020, Ryan Schmidt wrote:
> On May 20, 2020, at 21:09, Fred Wright wrote:
>
>>
>> Just because XQuartz is "out of date" doesn't mean that it might not be 
>> adequate in many cases, and I've found that switching from one X11 to 
>> another involves wrestling with some poorly documented configuration 
>> stuff, sometimes unsuccessfully.  So forcing someone who already has 
>> XQuartz (or Apple's X11, for that matter) installed and working to 
>> switch to the MacPorts xorg-server could inflict unnecessary pain.
>
> XQuartz and xorg-server are the same software, maintained until a few 
> years ago by the same person. He has become unavailable due to other 
> commitments and has stopped updating XQuartz and contributing to 
> MacPorts. Someone else has taken over keeping the MacPorts ports 
> updated. But they are the same software and should require no different 
> configuration.

I found my notes on switching.  What I'd found, by trial and error (not 
documentation), is that switching requires using some launchctl commands 
to switch the startx.plist, and it's necessary to reboot since logging out 
and logging in is insufficient (in spite of the classification as an 
"agent" rather than a "daemon").  And that procedure didn't work on the 
PowerBook, so there I wound up going back to XQuartz just to have a 
working X11.

> Apple's X11 only exists on Mac OS X 10.6 and earlier so it's not very 
> interesting to talk about at this point.

Well, some of us run old systems for testing. :-) And I believe Apple's 
X11 was provided at least as late as 10.7 as well.

>>> "could not open display" is a pretty normal error for an X11 app to 
>>> give when it can't find the X11 server. I don't see an entry in our 
>>> FAQ wiki page for this error. We could add one that tells the user how 
>>> to install and set up the xorg-server port.
>>
>> That's also the error that one gets when there's a perfectly good X11 
>> server installed but DISPLAY isn't set appropriately, so a distinction 
>> needs to be made between those cases.  I've also seen a case where a 
>> missing DISPLAY results in a segfault from Gtk.
>
> macOS sets DISPLAY properly for you, ever since Mac OS X 10.5. So 
> talking about a misconfigured DISPLAY isn't very interesting either; it 
> would take a concerted effort on the user's part to deliberately set a 
> wrong value.

I assure you that I hadn't engaged in any "concerted effort" to screw 
myself when I got burned by this issue.  And there was a time when it 
mattered whether one was launching from xterm or Terminal, though that 
discrepancy seems to have disappeared for no known reason.

>> The best approach might be simply to have a conditional port note in 
>> any X11 app, that checks to see whether *some* X11 server is present, 
>> and gives a warning with an installation suggestion if not.
>
> What I'm trying to avoid is having to add boilerplate code to hundreds 
> of ports. So I guess that means yet another portgroup to do this. But

Sure - doing it in a PortGroup makes sense regardless of what it actually 
does.

> even that -- editing hundreds of possibly optionally X11-using portfiles 
> to insert the inclusion of that portgroup only when X11 is actually 
> going to be used -- is a big effort.

Yup.  And this peripherally relates to the +x11 vs. +quartz issue that 
shows up all over the place.  At one point I started going down the rabbit 
hole of switching to +quartz as much as possible to minimize X11 
dependencies, but that proved to be too much of a nightmare.

On Wed, 20 May 2020, Ken Cunningham wrote:

> i was imagining just one key port — gtk, or some other always installed 
> required supporting lib — would do the test.

I don't think gtk is remotely close to being an always-required lib for 
X11 apps.

Fred Wright