Hi everyone, I just released the fourth (and probably last) beta for 2.5.1. If all goes smoothly, we'll be starting the rc's with the next release. This release pulls in the newly released xorg-server-1.8.1 and pixman-0.18.2. It also includes the work I've been doing recently for libxcb including the patch series I sent to xorg-devel yesterday which will make libxcb understand a larger set of $DISPLAY variables. This should fix the connectivity regressions that some people were seeing with the new xcb-backed libX11. We have 28 closed tickets with 7 remaining open in the 2.5.1 milestone. I'll be evaluating these to decide which to keep in 2.5.1 and which to punt to 2.5.2. If you feel strongly about any of these issues, please speak up. Full ChangeLog: http://xquartz.macosforge.org/trac/wiki/ChangeLog Direct Download: http://static.macosforge.org/xquartz/downloads/SL/XQuartz-2.5.1_beta4.dmg Remaining 2.5.1 issues: http://xquartz.macosforge.org/trac/query?status=assigned&status=new&status=r... Yes, this is SL-only. The first rc will be available for Leopard. Thanks, Jeremy
Thu, 13 May 2010 (08:25 -0700 UTC) Jeremy Huddleston wrote:
Hi everyone,
I just released the fourth (and probably last) beta for 2.5.1. If all goes smoothly, we'll be starting the rc's with the next release.
This release pulls in the newly released xorg-server-1.8.1 and pixman-0.18.2. It also includes the work I've been doing recently for libxcb including the patch series I sent to xorg-devel yesterday which will make libxcb understand a larger set of $DISPLAY variables. This should fix the connectivity regressions that some people were seeing with the new xcb-backed libX11.
We have 28 closed tickets with 7 remaining open in the 2.5.1 milestone. I'll be evaluating these to decide which to keep in 2.5.1 and which to punt to 2.5.2. If you feel strongly about any of these issues, please speak up.
Full ChangeLog: http://xquartz.macosforge.org/trac/wiki/ChangeLog
Direct Download: http://static.macosforge.org/xquartz/downloads/SL/XQuartz-2.5.1_beta4.dmg
Remaining 2.5.1 issues: http://xquartz.macosforge.org/trac/query?status=assigned&status=new&status=r...
Yes, this is SL-only. The first rc will be available for Leopard.
Thanks, Jeremy
With this beta, my app_to_run is no longer called. Also, the bug of not finding the correct display that was in an earlier version has returned in an odd way. Scripts called via the Applications menu start but bundles that contain the same scripts and which are in the dock get the wrong display (the one with the :0.0 rather than the :0). I just did an echo $DISPLAY in two xterms and found that both had DISPLAY as :4.0. Console messages complain that there is no /tmp/launch-LGszkt/org.macosforge.xquartz:0.0 I have reverted to beta3. -- rdr
On Thu, May 13, 2010 at 02:26:32PM -0400, robert delius royar wrote:
Thu, 13 May 2010 (08:25 -0700 UTC) Jeremy Huddleston wrote:
Hi everyone,
I just released the fourth (and probably last) beta for 2.5.1. If all goes smoothly, we'll be starting the rc's with the next release.
This release pulls in the newly released xorg-server-1.8.1 and pixman-0.18.2. It also includes the work I've been doing recently for libxcb including the patch series I sent to xorg-devel yesterday which will make libxcb understand a larger set of $DISPLAY variables. This should fix the connectivity regressions that some people were seeing with the new xcb-backed libX11.
We have 28 closed tickets with 7 remaining open in the 2.5.1 milestone. I'll be evaluating these to decide which to keep in 2.5.1 and which to punt to 2.5.2. If you feel strongly about any of these issues, please speak up.
Full ChangeLog: http://xquartz.macosforge.org/trac/wiki/ChangeLog
Direct Download: http://static.macosforge.org/xquartz/downloads/SL/XQuartz-2.5.1_beta4.dmg
Remaining 2.5.1 issues: http://xquartz.macosforge.org/trac/query?status=assigned&status=new&status=r...
Yes, this is SL-only. The first rc will be available for Leopard.
Thanks, Jeremy
With this beta, my app_to_run is no longer called. Also, the bug of not finding the correct display that was in an earlier version has returned in an odd way. Scripts called via the Applications menu start but bundles that contain the same scripts and which are in the dock get the wrong display (the one with the :0.0 rather than the :0). I just did an echo $DISPLAY in two xterms and found that both had DISPLAY as :4.0. Console messages complain that there is no /tmp/launch-LGszkt/org.macosforge.xquartz:0.0
I have reverted to beta3.
I has similar issues with the DISPLAY setting. Start up wouldn't doesn't start an xterm. Setting allow remote connects doesn't work. I had to do a xhost +. I've also reverted to beta3.
Doug Carter <dcarter@mercycorps.org> writes:
I has similar issues with the DISPLAY setting. Start up wouldn't doesn't start an xterm. Setting allow remote connects doesn't work. I had to do a xhost +.
I also see that no xterm is auto-launched at Xquartz start, and that $DISPLAY comes up as ":10.0" which I think is not what it's supposed to be? However, this is not breaking any of the stuff that's critical to me, so I think I can stay on beta4. BadValue font problem still there :-( regards, tom lane
On May 13, 2010, at 11:43, Doug Carter wrote:
I has similar issues with the DISPLAY setting. Start up wouldn't doesn't start an xterm. Setting allow remote connects doesn't work. I had to do a xhost +.
I've also reverted to beta3.
:: Place brown bag over face :: Ugg. My bad. I have a fix and will release beta5 shortly... These connection routines are fragile =/
2.5.1_beta5 has a fixed libxcb (with the patches actually applied this build). http://static.macosforge.org/xquartz/downloads/SL/XQuartz-2.5.1_beta5.dmg --Jeremy On May 13, 2010, at 21:59, Jeremy Huddleston wrote:
On May 13, 2010, at 11:43, Doug Carter wrote:
I has similar issues with the DISPLAY setting. Start up wouldn't doesn't start an xterm. Setting allow remote connects doesn't work. I had to do a xhost +.
I've also reverted to beta3.
:: Place brown bag over face ::
Ugg. My bad. I have a fix and will release beta5 shortly...
These connection routines are fragile =/
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Fri, May 14, 2010 at 1:43 AM, Jeremy Huddleston jeremyhu-at-apple.com |Xquartz-dev/Allow to me| <xkwek04oxk0t@sneakemail.com> wrote:
2.5.1_beta5 has a fixed libxcb (with the patches actually applied this build).
Hi Jeremy, I've got the "Focus On New Windows" option disabled, but new X windows are still being created on top of other Applications. The application focus isn't changing to XQuartz like it does when that option is checked, just the windows are being created above the current application's windows. Example: cover the display with a Terminal window, launch any X app from Terminal. Also, the bug is back where cmd-tabbing back to XQuartz doesn't bring its windows to the front, _only_if_ the Spaces option "When switching to an application, switch to a space with open windows for the application" is cleared. That was fixed before, at least for a while. This is my first 2.5.1_beta look; I'm pretty sure this wasn't the case in 2.5.0, but I'm not positive (haven't been using it as much, recently). Is it safe to just downgrade back to 2.5.0 with its installer to verify? Thanks, - Brian
On May 14, 2010, at 06:49, Brian Bender wrote:
On Fri, May 14, 2010 at 1:43 AM, Jeremy Huddleston jeremyhu-at-apple.com |Xquartz-dev/Allow to me| <xkwek04oxk0t@sneakemail.com> wrote:
2.5.1_beta5 has a fixed libxcb (with the patches actually applied this build).
Hi Jeremy,
I've got the "Focus On New Windows" option disabled, but new X windows are still being created on top of other Applications. The application focus isn't changing to XQuartz like it does when that option is checked, just the windows are being created above the current application's windows. Example: cover the display with a Terminal window, launch any X app from Terminal.
This is how it has always been, so it's not a regression... but I agree that it might be nice to "push them back" if this option is disabled. Can you please open a bug report for this, and I'll look into it for a future release: http://xquartz.macosforge.org/trac/newticket
Also, the bug is back where cmd-tabbing back to XQuartz doesn't bring its windows to the front, _only_if_ the Spaces option "When switching to an application, switch to a space with open windows for the application" is cleared. That was fixed before, at least for a while.
I don't think I ever actually fixed this. Perhaps you mean something different that what I understand. Can you make a screen capture of this using QuickTime?
This is my first 2.5.1_beta look; I'm pretty sure this wasn't the case in 2.5.0, but I'm not positive (haven't been using it as much, recently). Is it safe to just downgrade back to 2.5.0 with its installer to verify?
It should be. I haven't seen the downgrade failure issues that I had seen in Leopard's Installer.app. That being said, if you run into any downgrade problems, you can just uninstall first: http://xquartz.macosforge.org/trac/wiki/X11-UsersFAQ#UninstallSnowLeopard
On Fri, May 14, 2010 at 12:43 PM, Jeremy Huddleston jeremyhu-at-apple.com |Xquartz-dev/Allow to me| <xkwek04oxk0t@sneakemail.com> wrote:
application's windows. Example: cover the display with a Terminal window, launch any X app from Terminal.
This is how it has always been, so it's not a regression... but I agree that it might be nice to "push them back" if this option is disabled. Can you please open a bug report for this, and I'll look into it for a future release:
Sorry, I didn't remember seeing it. I'll file a report.
Also, the bug is back where cmd-tabbing back to XQuartz doesn't bring its windows to the front, _only_if_ the Spaces option "When switching to an application, switch to a space with open windows for the application" is cleared. That was fixed before, at least for a while.
I don't think I ever actually fixed this. Perhaps you mean something different that what I understand. Can you make a screen capture of this using QuickTime?
Pretty sure it got fixed right around the time Snow Leopard was released, but I (obviously <g>) could be wrong. I'll send a small screen-cap to your @apple address. Thanks, - Brian
Jeremy Huddleston <jeremyhu@apple.com> writes:
We have 28 closed tickets with 7 remaining open in the 2.5.1 milestone. I'll be evaluating these to decide which to keep in 2.5.1 and which to punt to 2.5.2. If you feel strongly about any of these issues, please speak up.
The font problem (ticket 325) is a serious, serious usability issue for me --- my email program crashes regularly because of that. If you can fix it for 2.5.1, pretty please? regards, tom lane
On May 13, 2010, at 16:44, Tom Lane wrote:
Jeremy Huddleston <jeremyhu@apple.com> writes:
We have 28 closed tickets with 7 remaining open in the 2.5.1 milestone. I'll be evaluating these to decide which to keep in 2.5.1 and which to punt to 2.5.2. If you feel strongly about any of these issues, please speak up.
The font problem (ticket 325) is a serious, serious usability issue for me --- my email program crashes regularly because of that. If you can fix it for 2.5.1, pretty please?
You have a workaround at least (don't include the system font directories in your font path).
Jeremy Huddleston <jeremyhu@apple.com> writes:
On May 13, 2010, at 16:44, Tom Lane wrote:
The font problem (ticket 325) is a serious, serious usability issue for me --- my email program crashes regularly because of that. If you can fix it for 2.5.1, pretty please?
You have a workaround at least (don't include the system font directories in your font path).
Hmm ... pardon my ignorance, but how would I do that? regards, tom lane
On May 15, 2010, at 10:46, Tom Lane wrote:
Jeremy Huddleston <jeremyhu@apple.com> writes:
On May 13, 2010, at 16:44, Tom Lane wrote:
The font problem (ticket 325) is a serious, serious usability issue for me --- my email program crashes regularly because of that. If you can fix it for 2.5.1, pretty please?
You have a workaround at least (don't include the system font directories in your font path).
Hmm ... pardon my ignorance, but how would I do that?
mkdir ~/.xinitrc.d cp /opt/X11/lib/X11/xinit/xinitrc.d/10-fontdir.sh ~/.xinitrc.d nano -w ~/.xinitrc.d/10-fontdir.sh Remove these two lines: [ -e /Library/Fonts/fonts.dir ] && fontpath="$fontpath,/Library/Fonts" [ -e /System/Library/Fonts/fonts.dir ] && fontpath="$fontpath,/System/Library/Fonts" --Jeremy
I have had reports of pymol crashing under X11 when used with a secondary display... https://trac.macports.org/ticket/24895 Unfortunately. I don't have any dual headed systems to test this with. Could someone with that configuration take a look at this with the MacPorts pymol package to see if it is a Xquartz bug? Also, if the Pymol viewer window flashes, starting the program with 'pymol -M' will suppress that by launching pymol in non-stereo mode. Jack
I commented in the ticket, but just thought I'd respond here as well. This sounds like a graphics driver issue. I'd report it at http://bugreport.apple.com On May 15, 2010, at 11:44, Jack Howarth wrote:
I have had reports of pymol crashing under X11 when used with a secondary display...
https://trac.macports.org/ticket/24895
Unfortunately. I don't have any dual headed systems to test this with. Could someone with that configuration take a look at this with the MacPorts pymol package to see if it is a Xquartz bug? Also, if the Pymol viewer window flashes, starting the program with 'pymol -M' will suppress that by launching pymol in non-stereo mode. Jack
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
participants (6)
-
Brian Bender
-
Doug Carter
-
Jack Howarth
-
Jeremy Huddleston
-
robert delius royar
-
Tom Lane