Hi folks, This weekend's update to XQuartz just includes some improvements to binary compatibility with older client apps (re-addition of i386 support and the flat-namespace libXt.6.dylib in /opt/X11/lib/flat_namespace) plus additional documentation and man pages where were missing in earlier builds. See more details at https://www.xquartz.org/releases/XQuartz-2.8.0_rc2.html If nothing serious comes up, I expect this will be the last release-candidate before release. Please report back if you run into any issues. Thanks, Jeremy
Hello! I have some problems with this version on Big Sur, macOS 11.2.2. It is XQuartz 2.8.0_rc2 (xorg-server 1.19.7) running, X clients used are /opt/X11/bin/xterm and a few versions of GNU Emacs. Window manager is blackbox. This one is missing its usual decoration, GNU Emacs from MacPorts is missing the usual fonts (could be libotf is not compiled in). The most obvious bug is that copy&paste does not work, neither in and between GNU Emacsen nor in xterm nor between Aqua (Terminal) and X11 – except that I just could copy xterm's full path name from xterm to Mail… The other way does not work. In XQuartz' menu I can see only Copy and no Paste. This one way function also works in GNU Emacs, i.e. copy from it into Mail. -- Greetings Pete It isn't pollution that's harming the environment. It's the impurities in our air and water that are doing it.
Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:
The most obvious bug is that copy&paste does not work, neither in and between GNU Emacsen nor in xterm nor between Aqua (Terminal) and X11 – except that I just could copy xterm's full path name from xterm to Mail… The other way does not work. In XQuartz' menu I can see only Copy and no Paste. This one way function also works in GNU Emacs, i.e. copy from it into Mail.
First thing is to check XQuartz's preferences to see if you have copy/paste turned on --- rc2 is supposed to be able to copy prefs from previous versions, but that failed earlier, and maybe it's still not right. Some of us have seen paste-from-XQuartz-to-macOS suddenly stop working, but not the other direction. Restarting XQuartz has fixed that for me. Can't speak to your font issues. regards, tom lane
Am 6.3.2021 um 17:27 schrieb Tom Lane <tgl@sss.pgh.pa.us>:
Some of us have seen paste-from-XQuartz-to-macOS suddenly stop working, but not the other direction. Restarting XQuartz has fixed that for me.
In Preferences all five boxes for copy&paste are checked. Restart was planned after re-build of GNU Emacs 28. I found a document about the new version of Blackbox WM – I think I have nor converted the appropriate files!
Can't speak to your font issues.
They certainly come from missing libotf. I haven't worked much with X11 on Big Sur, so its Portfile has not been corrected yet… -- Greetings Pete Sending unsolicited commercial eMail to this account incurs a fee of € 500 per message and acknowledges the legality of this contract.
Am 6.3.2021 um 17:27 schrieb Tom Lane <tgl@sss.pgh.pa.us>:
Some of us have seen paste-from-XQuartz-to-macOS suddenly stop working, but not the other direction. Restarting XQuartz has fixed that for me.
It's possibly better to just check whether a three button mouse is being emulated – if it is (checked), then copy&paste works perfectly! So can I now try to get rid of my own bugs… -- Greetings Pete A mathematician is a device for turning coffee into theorems. – Erdős Pál
Am 27.2.2021 um 22:50 schrieb Jeremy Huddleston Sequoia <jeremyhu@apple.com>:
On High Sierra I had to activate the emulation of a three button mouse, too. There and on Big Sur it worked to compile X clients (GNU Emacsen) with libraries taken off /opt/X11 and /opt/local (MacPorts). It also worked to run X clients from questionable background (not knowing how they were built) and they all displayed fine. IMO the window titles use a too large font… It even works to run two X servers (in the same or different spaces)… -- Greetings Pete Je pompe donc je suis
Am 27.2.2021 um 22:50 schrieb Jeremy Huddleston Sequoia <jeremyhu@apple.com>:
There is a problem in adding additional entries to the list of applications in the Applications menu. When German is set by System Preferences as language then it seems that it's not possible to add text to the newly added line or remove it. In English all works. -- Greetings Pete Progress (n.): Process through which USENET evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.
Am 8.3.2021 um 16:15 schrieb Peter Dyballa <Peter_Dyballa@Freenet.DE>:
Am 27.2.2021 um 22:50 schrieb Jeremy Huddleston Sequoia <jeremyhu@apple.com>:
There is a problem in adding additional entries to the list of applications in the Applications menu. When German is set by System Preferences as language then it seems that it's not possible to add text to the newly added line or remove it. In English all works.
To be exact: it's not *all* that works, it just works once. In the same session I cannot customise the menu. I can add empty read-only lines and I can duplicate any line into a read-only line but I cannot change these duplicated lines. Only removal works. -- Greetings Pete Time flies like an error – but fruit flies like a banana! - (almost) Groucho Marx
Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:
There is a problem in adding additional entries to the list of applications in the Applications menu. When German is set by System Preferences as language then it seems that it's not possible to add text to the newly added line or remove it. In English all works.
To be exact: it's not *all* that works, it just works once. In the same session I cannot customise the menu. I can add empty read-only lines and I can duplicate any line into a read-only line but I cannot change these duplicated lines. Only removal works.
I saw some other weird behavior of the applications menu in an earlier 2.8.0 beta --- see Jan 31 comment on https://github.com/XQuartz/XQuartz/issues/32 I don't think that was actually fixed, but it's hard to fix something you can't reproduce ... regards, tom lane
Am 27.2.2021 um 22:50 schrieb Jeremy Huddleston Sequoia <jeremyhu@apple.com>:
The GNU Emacsen I launch from ~/.xinitrc or XTerm have their working directory in / while XTerm's shell sets it to ~. When I launch GNU Emacs from the Applications menu its working directory is ~. -- Greetings Pete Government is actually the worst failure of civilized man. There has never been a really good one, and even those that are most tolerable are arbitrary, cruel, grasping and unintelligent. – H. L. Mencken
On Mar 8, 2021, at 08:03, Peter Dyballa <Peter_Dyballa@Freenet.DE> wrote:
Am 27.2.2021 um 22:50 schrieb Jeremy Huddleston Sequoia <jeremyhu@apple.com>:
The GNU Emacsen I launch from ~/.xinitrc or XTerm have their working directory in / while XTerm's shell sets it to ~.
When I launch GNU Emacs from the Applications menu its working directory is ~.
Could you file a bug report for this at https://github.com/XQuartz/XQuartz/issues/new It should be a simple fix to add a 'cd ~' to the startx script to ensure this is consistent. We do that in XQuartz.app's startup script, but should probably do the same for startx.
-- Greetings
Pete
Government is actually the worst failure of civilized man. There has never been a really good one, and even those that are most tolerable are arbitrary, cruel, grasping and unintelligent. – H. L. Mencken
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
Am 10.3.2021 um 08:20 schrieb Jeremy Huddleston Sequoia <jeremyhu@apple.com>:
Could you file a bug report for this at https://github.com/XQuartz/XQuartz/issues/new
Done! I found another issue with XQuartz: It does not start XTerms from ~/.xinitrc. I have now: 74 /opt/X11/bin/xterm -T ".XinitRC" & 75 xterm -T "`which xterm`" & 76 /opt/local/bin/xterm -T ".XinitRC3" & 77 env LC_NUMERIC=C /usr/local/bin/emacs-27.1.91 -geometry 100x55+1221+167 -T 27.1.91 --debug-init -fn 'Lucida Sans Typewriter:autohint=true:antialias=true:size=9' & 78 env LC_NUMERIC=C /usr/local/bin/emacs-28.0.50 -geometry 99x66+200+234 -T 28.0.50 --debug-init -fn 'Lucida Sans Typewriter:autohint=true:antialias=true:size=8' & and I also had the Emacsen before XTerm. Only the initial XTerm from startx/xinit is launched. X11 from MacPorts launches all 3 XTerms. I have one more observation: From time to time, maybe when XQuartz has run for a minute or so and I quit, after having quit the Emacsen with Ctrl-X Ctrl-C, then the cursor sometimes vanishes. When I press Return or Tab it seems XTerm has the focus with an invisible cursor. I cannot quit XQuartz. It seems to work to move the (invisible) around and then click somewhere. This makes it reappear. X11 and XQuartz show sometimes a strange behaviour. Could be it happened more often or solely when I quit GNU Emacs 27.1.91. The Blackbox WM seems to have passed the focus to XTerm – which prints endlessly cccccccccccc – until I press some key. Are they worth three reports? -- Greetings Pete A blizzard is when it snows sideways.
Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:
I have one more observation: From time to time, maybe when XQuartz has run for a minute or so and I quit, after having quit the Emacsen with Ctrl-X Ctrl-C, then the cursor sometimes vanishes.
I've been having problems with the cursor going invisible too, but haven't managed to characterize the trigger condition well enough for a bug report. Clicking brings it back, but it's a little scary to click when you aren't sure what you might be clicking on. regards, tom lane
Am 10.3.2021 um 13:26 schrieb Peter Dyballa <Peter_Dyballa@Freenet.DE>:
X11 and XQuartz show sometimes a strange behaviour. Could be it happened more often or solely when I quit GNU Emacs 27.1.91. The Blackbox WM seems to have passed the focus to XTerm – which prints endlessly cccccccccccc – until I press some key.
On High Sierra, macOS 10.13.6, this behaviour is more pronounced. I could even made the keyboard driver (?) to produce this "c" series in the GNU Emacs that was left alive. And of course in XTerm. In both X11 and XQuartz. -- Greetings Pete Add 15 inches to your stride and save 4% of insects! – Ivor Cutler
Am 10.3.2021 um 16:41 schrieb Peter Dyballa <Peter_Dyballa@Freenet.DE>:
Am 10.3.2021 um 13:26 schrieb Peter Dyballa <Peter_Dyballa@Freenet.DE>:
X11 and XQuartz show sometimes a strange behaviour. Could be it happened more often or solely when I quit GNU Emacs 27.1.91. The Blackbox WM seems to have passed the focus to XTerm – which prints endlessly cccccccccccc – until I press some key.
On High Sierra, macOS 10.13.6, this behaviour is more pronounced. I could even made the keyboard driver (?) to produce this "c" series in the GNU Emacs that was left alive. And of course in XTerm. In both X11 and XQuartz.
The High Sierra Mac is a bit slower, which might be helpful. I started a new experiment – in GNU Emacs 28.0.50. Before I had the pre-occupation that GNU Emacs 27.1.91 was the culprit, so I opened a file in GNU Emacs 28.0.50, changed it, and left its contents unsaved when I tried to quit with Ctrl-X Ctrl-C. GNU Emacs 28.0.50 was forced to ask me whether I wanted to have the changed file saved. Of course, so I typed "y". The result was that "something" wrote into GNU Emacs 27.1.91 a lot of "y". I pressed RET and wanted to quit – but GNU Emacs 27.1.91 only received Ctrl-C… Well, I have to alter my pre-occupation: GNU Emacs 28.0.50 seems to be the culprit. This is some experimental version checked out from GitHub. It seems to have – or have had – a bug… -- Greetings Pete He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty, he establishes a precedent that will reach to himself. – Thomas Paine
Am 10.3.2021 um 13:26 schrieb Peter Dyballa <Peter_Dyballa@Freenet.DE>:
I found another issue with XQuartz: It does not start XTerms from ~/.xinitrc. I have now:
74 /opt/X11/bin/xterm -T ".XinitRC" & 75 xterm -T "`which xterm`" & 76 /opt/local/bin/xterm -T ".XinitRC3" & 77 env LC_NUMERIC=C /usr/local/bin/emacs-27.1.91 -geometry 100x55+1221+167 -T 27.1.91 --debug-init -fn 'Lucida Sans Typewriter:autohint=true:antialias=true:size=9' & 78 env LC_NUMERIC=C /usr/local/bin/emacs-28.0.50 -geometry 99x66+200+234 -T 28.0.50 --debug-init -fn 'Lucida Sans Typewriter:autohint=true:antialias=true:size=8' &
and I also had the Emacsen before XTerm. Only the initial XTerm from startx/xinit is launched. X11 from MacPorts launches all 3 XTerms.
Again, this behaviour is on High Sierra reversed. XQuartz launches the XTerms which X11 does not! Is Launch Service causing this? -- Greetings Pete Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration. – Donald Knuth
Am 8.3.2021 um 17:03 schrieb Peter Dyballa <Peter_Dyballa@Freenet.DE>:
The GNU Emacsen I launch from ~/.xinitrc or XTerm have their working directory in / while XTerm's shell sets it to ~.
On High Sierra it's exactly opposite: XQuartz provides ~ while MacPorts' X11 gives /… I'm going to check what X clients from the Applications menu will get! -- Greetings Pete Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. – Albert Einstein
Am 27.2.2021 um 22:50 schrieb Jeremy Huddleston Sequoia <jeremyhu@apple.com>:
By putting some diagnostics in ~/.xinitrc (echo "something" >> file) I saw that XQuartz adds /usr/X11R6/bin to PATH, and /usr/X11R6 is a symbolic link to /opt/X11. So there's no need to treat XQuartz different. -- Greetings Pete Bake pizza not war!
participants (3)
-
Jeremy Huddleston Sequoia
-
Peter Dyballa
-
Tom Lane