Hey everyone, I'd like to announce that the second release candidate of XQuartz 2.7.8 is available. The main changes since the first release candidate are: * mesa has been updated to version 11.0.3 * freetype has been updated to version 2.6.1 * multiple bug fixes from X.org packages * Post-install script edits the correct ssh config locations on El Capitan * Post-install script executes x11-select directly on El Capitan Please test it out and report back any issues: http://xquartz.macosforge.org/downloads/SL/XQuartz-2.7.8_rc2.dmg http://xquartz.macosforge.org/trac/wiki/X112.7.8 Thanks, Jeremy
Hello, The rc2 that was just released is causing a 'hidden border' along the top of every x11 window. The 'native' OSX apps do not experience this. Nor does the previous rc1 release. I have the "X11 root window" option turned 'off'/Un-checked. I'll do a screen grab to try showing this (if attachments will work thru this maillist). At any rate: The screengrab shows 3 of my Pan windows (usenet reader for GNome/X11) in front of the OSX Activity Monitor window. I've already tried dragging the Pan windows as high as they're allowed to go with 278rc2 running, showing around a 50-pixel gap there. This gap was not there when running 278rc1 and prior meaning I could drag any window to use the full area on the hardware LCD screen. Note my personal life has not changed any at all --- I am still on Disability with No End in Sight, I am still running OSX-10.6.8 on the same model "iMac6,1" which is explained here, <http://www.everymac.com/systems/apple/imac/specs/imac-core-2-duo-2.16-24-inch-specs.html> I cannot afford to upgrade at all (even to 'join' the MAS to get 'free' apps etc since MAS still needs proof-of-purchase mechanism from me) so updates to OSX-10.7 etc will not happen. I've been unable to boot-up various ISO disk images properly for running open-source systems (can explain this separately -- I'd much-rather switch to such a system if able to boot it up fully). When this machine dies, I will be without a 'puter and without a primary source of communication, so any help is greatly appreciated and I'm unashamedly asking for it here among other places. Thank you.
Can you try installing 2.7.8_rc1, backing up /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin, updating to 2.7.8_rc2, and then replacing that file with the old one? I suspect this is a regression from http://cgit.freedesktop.org/~jeremyhu/xserver/commit/?h=server-1.16-apple&id...
On Oct 12, 2015, at 19:59, SciFi <sci-fi@hush.ai> wrote:
Hello,
The rc2 that was just released is causing a 'hidden border' along the top of every x11 window.
The 'native' OSX apps do not experience this. Nor does the previous rc1 release.
I have the "X11 root window" option turned 'off'/Un-checked.
I'll do a screen grab to try showing this (if attachments will work thru this maillist).
At any rate: The screengrab shows 3 of my Pan windows (usenet reader for GNome/X11) in front of the OSX Activity Monitor window. I've already tried dragging the Pan windows as high as they're allowed to go with 278rc2 running, showing around a 50-pixel gap there.
This gap was not there when running 278rc1 and prior meaning I could drag any window to use the full area on the hardware LCD screen.
Note my personal life has not changed any at all --- I am still on Disability with No End in Sight, I am still running OSX-10.6.8 on the same model "iMac6,1" which is explained here, <http://www.everymac.com/systems/apple/imac/specs/imac-core-2-duo-2.16-24-inch-specs.html> I cannot afford to upgrade at all (even to 'join' the MAS to get 'free' apps etc since MAS still needs proof-of-purchase mechanism from me) so updates to OSX-10.7 etc will not happen. I've been unable to boot-up various ISO disk images properly for running open-source systems (can explain this separately -- I'd much-rather switch to such a system if able to boot it up fully). When this machine dies, I will be without a 'puter and without a primary source of communication, so any help is greatly appreciated and I'm unashamedly asking for it here among other places.
Thank you.
<XQ278rc2_causing-this-hidden-border.png> _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
I'll try doing that, might be a while ;) On 2015/10/12 22:09, Jeremy Huddleston Sequoia wrote:
Can you try installing 2.7.8_rc1, backing up /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin, updating to 2.7.8_rc2, and then replacing that file with the old one?
I suspect this is a regression from http://cgit.freedesktop.org/~jeremyhu/xserver/commit/?h=server-1.16-apple&id...
On Oct 12, 2015, at 19:59, SciFi <sci-fi@hush.ai> wrote:
Hello,
The rc2 that was just released is causing a 'hidden border' along the top of every x11 window.
The 'native' OSX apps do not experience this. Nor does the previous rc1 release.
I have the "X11 root window" option turned 'off'/Un-checked.
I'll do a screen grab to try showing this (if attachments will work thru this maillist).
At any rate: The screengrab shows 3 of my Pan windows (usenet reader for GNome/X11) in front of the OSX Activity Monitor window. I've already tried dragging the Pan windows as high as they're allowed to go with 278rc2 running, showing around a 50-pixel gap there.
This gap was not there when running 278rc1 and prior meaning I could drag any window to use the full area on the hardware LCD screen.
Note my personal life has not changed any at all --- I am still on Disability with No End in Sight, I am still running OSX-10.6.8 on the same model "iMac6,1" which is explained here, <http://www.everymac.com/systems/apple/imac/specs/imac-core-2-duo-2.16-24-inch-specs.html> I cannot afford to upgrade at all (even to 'join' the MAS to get 'free' apps etc since MAS still needs proof-of-purchase mechanism from me) so updates to OSX-10.7 etc will not happen. I've been unable to boot-up various ISO disk images properly for running open-source systems (can explain this separately -- I'd much-rather switch to such a system if able to boot it up fully). When this machine dies, I will be without a 'puter and without a primary source of communication, so any help is greatly appreciated and I'm unashamedly asking for it here among other places.
Thank you.
<XQ278rc2_causing-this-hidden-border.png> _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
On Oct 12, 2015, at 10:09 PM, Jeremy Huddleston Sequoia <jeremyhu@apple.com> wrote:
Can you try installing 2.7.8_rc1, backing up /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin, updating to 2.7.8_rc2, and then replacing that file with the old one?
I suspect this is a regression from http://cgit.freedesktop.org/~jeremyhu/xserver/commit/?h=server-1.16-apple&id...
diff --git a/hw/xquartz/X11Application.m b/hw/xquartz/X11Application.m index 2efbd65..a9ee693 100644 --- a/hw/xquartz/X11Application.m +++ b/hw/xquartz/X11Application.m @@ -1240,7 +1240,7 @@ X11ApplicationMain(int argc, char **argv, char **envp)
/* Calculate the height of the menubar so we can avoid it. */ aquaMenuBarHeight = NSHeight([[NSScreen mainScreen] frame]) - - NSMaxY([[NSScreen mainScreen] visibleFrame]); + NSHeight([[NSScreen mainScreen] visibleFrame]);
#ifdef HAVE_LIBDISPATCH eventTranslationQueue = dispatch_queue_create(
+[NSScreen mainScreen] does not mean the primary display. It used to mean the one with the key window. When "Displays have separate spaces" is enabled, it means the active screen, the one whose menu bar is mostly opaque. As such, it may not be the screen whose lower-left corner is located at (0, 0). That's why its max-Y is not necessarily comparable to its height. That only works for the primary display. This code could use [[NSScreen screens] firstObject]. This is always the primary display, the one whose lower-left corner is at (0, 0). Once that's done, the above change should be reverted. The height of the visible frame would be the full height of the screen minus the menu bar _and the Dock_ if the Dock is along the bottom of the screen. Actually, there's a theoretically-simpler approach: use -[NSMenu menuBarHeight]. That replaces a long-deprecated method +[NSMenuView menuBarHeight]. However, there was a bug in Tiger that led to the former not working while the latter still worked. I haven't actually checked recently. CrossOver's still-kicking X server code uses this code, which tries all of the above: NSScreen* primaryScreen = [[NSScreen screens] objectAtIndex:0]; aquaMenuBarHeight = [[NSApp mainMenu] menuBarHeight]; if (!aquaMenuBarHeight) aquaMenuBarHeight = [NSMenuView menuBarHeight]; if (!aquaMenuBarHeight) aquaMenuBarHeight = NSHeight([primaryScreen frame]) - NSMaxY([primaryScreen visibleFrame]); Regards, Ken
Thanks Ken. Tom, could you give Ken's suggested logic a try and make sure it works for you? Could you send a followup patch? If not, I'll try to knock that out when I get some more cycles. --Jeremy
On Oct 12, 2015, at 20:44, Ken Thomases <ken@codeweavers.com> wrote:
On Oct 12, 2015, at 10:09 PM, Jeremy Huddleston Sequoia <jeremyhu@apple.com> wrote:
Can you try installing 2.7.8_rc1, backing up /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin, updating to 2.7.8_rc2, and then replacing that file with the old one?
I suspect this is a regression from http://cgit.freedesktop.org/~jeremyhu/xserver/commit/?h=server-1.16-apple&id...
diff --git a/hw/xquartz/X11Application.m b/hw/xquartz/X11Application.m index 2efbd65..a9ee693 100644 --- a/hw/xquartz/X11Application.m +++ b/hw/xquartz/X11Application.m @@ -1240,7 +1240,7 @@ X11ApplicationMain(int argc, char **argv, char **envp)
/* Calculate the height of the menubar so we can avoid it. */ aquaMenuBarHeight = NSHeight([[NSScreen mainScreen] frame]) - - NSMaxY([[NSScreen mainScreen] visibleFrame]); + NSHeight([[NSScreen mainScreen] visibleFrame]);
#ifdef HAVE_LIBDISPATCH eventTranslationQueue = dispatch_queue_create(
+[NSScreen mainScreen] does not mean the primary display. It used to mean the one with the key window. When "Displays have separate spaces" is enabled, it means the active screen, the one whose menu bar is mostly opaque. As such, it may not be the screen whose lower-left corner is located at (0, 0). That's why its max-Y is not necessarily comparable to its height. That only works for the primary display.
This code could use [[NSScreen screens] firstObject]. This is always the primary display, the one whose lower-left corner is at (0, 0).
Once that's done, the above change should be reverted. The height of the visible frame would be the full height of the screen minus the menu bar _and the Dock_ if the Dock is along the bottom of the screen.
Actually, there's a theoretically-simpler approach: use -[NSMenu menuBarHeight]. That replaces a long-deprecated method +[NSMenuView menuBarHeight]. However, there was a bug in Tiger that led to the former not working while the latter still worked. I haven't actually checked recently.
CrossOver's still-kicking X server code uses this code, which tries all of the above:
NSScreen* primaryScreen = [[NSScreen screens] objectAtIndex:0]; aquaMenuBarHeight = [[NSApp mainMenu] menuBarHeight]; if (!aquaMenuBarHeight) aquaMenuBarHeight = [NSMenuView menuBarHeight]; if (!aquaMenuBarHeight) aquaMenuBarHeight = NSHeight([primaryScreen frame]) - NSMaxY([primaryScreen visibleFrame]);
Regards, Ken
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
I've got 2.7.8 rc3 installed now, and it seems to work fine, even after some attempts to break it. Thanks, --Tom Seddon On 13/10/2015 06:27, Jeremy Huddleston Sequoia wrote:
Thanks Ken.
Tom, could you give Ken's suggested logic a try and make sure it works for you? Could you send a followup patch? If not, I'll try to knock that out when I get some more cycles.
--Jeremy
On Oct 12, 2015, at 20:44, Ken Thomases <ken@codeweavers.com> wrote:
On Oct 12, 2015, at 10:09 PM, Jeremy Huddleston Sequoia <jeremyhu@apple.com> wrote:
Can you try installing 2.7.8_rc1, backing up /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin, updating to 2.7.8_rc2, and then replacing that file with the old one?
I suspect this is a regression from http://cgit.freedesktop.org/~jeremyhu/xserver/commit/?h=server-1.16-apple&id...
diff --git a/hw/xquartz/X11Application.m b/hw/xquartz/X11Application.m index 2efbd65..a9ee693 100644 --- a/hw/xquartz/X11Application.m +++ b/hw/xquartz/X11Application.m @@ -1240,7 +1240,7 @@ X11ApplicationMain(int argc, char **argv, char **envp)
/* Calculate the height of the menubar so we can avoid it. */ aquaMenuBarHeight = NSHeight([[NSScreen mainScreen] frame]) - - NSMaxY([[NSScreen mainScreen] visibleFrame]); + NSHeight([[NSScreen mainScreen] visibleFrame]);
#ifdef HAVE_LIBDISPATCH eventTranslationQueue = dispatch_queue_create(
+[NSScreen mainScreen] does not mean the primary display. It used to mean the one with the key window. When "Displays have separate spaces" is enabled, it means the active screen, the one whose menu bar is mostly opaque. As such, it may not be the screen whose lower-left corner is located at (0, 0). That's why its max-Y is not necessarily comparable to its height. That only works for the primary display.
This code could use [[NSScreen screens] firstObject]. This is always the primary display, the one whose lower-left corner is at (0, 0).
Once that's done, the above change should be reverted. The height of the visible frame would be the full height of the screen minus the menu bar _and the Dock_ if the Dock is along the bottom of the screen.
Actually, there's a theoretically-simpler approach: use -[NSMenu menuBarHeight]. That replaces a long-deprecated method +[NSMenuView menuBarHeight]. However, there was a bug in Tiger that led to the former not working while the latter still worked. I haven't actually checked recently.
CrossOver's still-kicking X server code uses this code, which tries all of the above:
NSScreen* primaryScreen = [[NSScreen screens] objectAtIndex:0]; aquaMenuBarHeight = [[NSApp mainMenu] menuBarHeight]; if (!aquaMenuBarHeight) aquaMenuBarHeight = [NSMenuView menuBarHeight]; if (!aquaMenuBarHeight) aquaMenuBarHeight = NSHeight([primaryScreen frame]) - NSMaxY([primaryScreen visibleFrame]);
Regards, Ken
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
participants (5)
-
Jeremy Huddleston Sequoia
-
Jeremy Huddleston Sequoia
-
Ken Thomases
-
SciFi
-
Tom Seddon