I installed xQuartz on a Yosemite laptop (X11 was zapped by upgrade)
without problem.
I installed xQuartz on a Snow Leopard desktop that still had X11 without
problems.
So, I did the same on my Snow Leopard Server (xServe). However, the
xQuartz.app refuses to start and the log files fill up with
Got prompted to upgrade to 2.7.9 today which I promptly did.
After the update, the xserver on my desktop is no longer listening to
port 6000, so scripts from my server can't pop windows onto my Max.
the defaults show:
"nolisten_tcp" = 0;
The SECURITY tab in Preferences for Xquartz
If the problem occurs only on certain screen drawing activities, one
possibility is that the remote system thinks your are 8-bit-controls
enabled but the terminal emulator (xterm) doesn't, si it receives from
remote host escape sequences that it doesn't process and hence gibberish
on screen.
vi
On 2016-06-05 23:00, Jeremy Huddleston Sequoia wrote:
>>> Yes, /opt/local/bin/startx
>>
>> /usr/X11/bin on my Yosemite system.
>
> Oops. I meant /opt/X11/bin/startx.
>
> /usr/X11 is a compatibility symlink to /opt/X11 for 3rd party apps that built
> against X11 in the Lion and earlier SDKs.
On 2016-06-05 20:33, Jeremy Huddleston Sequoia wrote:
> Yes, /opt/local/bin/startx
/usr/X11/bin on my Yosemite system.
I am guessing installation uses existing location so it has remained in
old location despite impending doom when/if I goto ElCapitan.
Defaults reveals:
"startx_script" =
I have a desktop which acts as X11 server for a number of windows from
other machines/servers.
With recent versions of OS-X ^H^H^H^H macOS, there were some changes
made to allow some activity during sleep. I am not entirely familiar
with the mechanics but it is called "Power Nap".
One of the
On 2016-08-06 14:21, Brandon Allbery wrote:
> Sigh. So something else is clearing it. The terminal is started with
> $DISPLAY set correctly (if it weren't, the terminal window wouldn't even
> show up) so something in your shell session is clearing $DISPLAY.
More complete test:
after having
On 2016-08-06 14:04, Brandon Allbery wrote:
> This means your dotfiles (probably cribbed from Linux) are overriding
> $DISPLAY. Don't do that; there is no guarantee that the display is actually
> :0, and the persistent security access keys are indexed by the $DISPLAY set
> by launchd not the
On 2016-09-18 16:52, Markus Gschwind wrote:
> After hibernation mode, the Xterm is lost and therefore the open windows of
> these apps are gone (without saving the workspace). This is very annoying
> and seems to be new since I upgraded from OSX 10.6.8 to 10.9.5.
The problem has existed for a
Notes:
"wake for network access" is a protocol where one sends a carefully
crafted Ethernet packet and the ethernet card, upon receiving it, sends
a "wake up" signal to the machine.
Normal apps don't send those packets that cause a wake up.
And in terms of "keep alive" a connection, there would
> After login, the X11 application automatically opens.
> It is actually installed in /Applications/MacPorts
I have had a lot of annoyances with MACports and finally weeded my
systems of anything macport. Is there a way to build the Macports
version of XQuart to be "native" on my system
ps -a -f
bike:~ $ ps -a -f -x | grep 9780
501 9780 1 0 6:22PM ?? 0:00.28 /opt/X11/bin/xterm
501 9968 9780 0 6:22PM ttys0000:00.01 bash
501 10057 10029 0 6:31PM ttys0000:00.00 grep 9780
One would have to look at the xterm code which creates the process whose
Some time ago, in a newsgroud discussion, there was a discussion about
file access for line commands. I don't recall the specifics because
discussion quickly turned to insults, but there are some under-the-hood
inheritances.
I am sticking to High Sierra, so not affected by this.
There is a
On 2020-01-04 03:34, Gunning, James (Energy, Clayton North) via
X11-users wrote:
> Hi All,
> I'm running Xquartz from the Macports build on High Sierra.
I am running the "Apple suppoted" older version on High Sierrs
XQuartz 2.7.11 (xorg-server 1.18.4)
Apart from a few hiccups here and
Couple of generic comments:
Since ARM and Intel share little-endian and 64 bits, the code should
compile cleanly.
However, Apple has mentioned that it will be using its own graphics
cards on the new ARM-based Macs I am more concerned about whether the
graphical API used by XQuartz continues to
Platforms State of the Union:
https://developer.apple.com/videos/play/wwdc2020/102/
at 15:30
And they will be amazing Unix Machine fopr developpers and scientific
communities for any software they like.
Perhaps some pressure on Apple to produce a new XQuarts kit that can
easily be installed
16 matches
Mail list logo
