Discussion:
[Xquartz-dev] XQuartz 2.7.8_rc2
Jeremy Huddleston Sequoia
2015-10-13 00:56:01 UTC
Permalink
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
SciFi
2015-10-13 02:59:35 UTC
Permalink
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.
Jeremy Huddleston Sequoia
2015-10-13 03:09:23 UTC
Permalink
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=cac50177f99fb819bfaeea1f2ac33e38fc574eb3
Post by SciFi
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).
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
https://lists.macosforge.org/mailman/listinfo/xquartz-dev
SciFi
2015-10-13 03:14:56 UTC
Permalink
I'll try doing that,
might be a while
;)
Post by Jeremy Huddleston Sequoia
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=cac50177f99fb819bfaeea1f2ac33e38fc574eb3
Post by SciFi
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).
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
https://lists.macosforge.org/mailman/listinfo/xquartz-dev
Ken Thomases
2015-10-13 03:44:54 UTC
Permalink
Post by Jeremy Huddleston Sequoia
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=cac50177f99fb819bfaeea1f2ac33e38fc574eb3
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
Jeremy Huddleston Sequoia
2015-10-13 05:27:40 UTC
Permalink
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
Post by Ken Thomases
Post by Jeremy Huddleston Sequoia
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=cac50177f99fb819bfaeea1f2ac33e38fc574eb3
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.
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
https://lists.macosforge.org/mailman/listinfo/xquartz-dev
Jeremy Huddleston Sequoia
2015-10-13 16:48:22 UTC
Permalink
Hey guys,

Thanks for all this feedback regarding the window placement issue. I'd really like to be able to reproduce the issue myself to verify that the proposed solution addresses the problem, but I am not seeing the issue on my machine.

For those of you reproducing, can you please fill in the following data?

OS X Version:

Is "Displays have Different Spaces" enabled in System Preferences -> Mission Control / Spaces?:

Number of displays connected:

For each display, is it traditional (1x) or retina (2x)?:

If multiple displays, what is their arrangement (a screenshot from Display Preferences would be perfect):

Thanks,
Jeremy
I tried 278rc2 and find I can not move X windows higher on my screen than about 90 pixels from the menu bar. See attached screenshot showing 3 Terminal windows as close to the menu bar as I can drag them. It's like there's an invisible barrier there!
Same issue. I'm running 10.11.
It also took a LONG time to install - spent over 10 minutes at the final step with estimated time 1 minute remaining.
That issue I did not experience. The install transpired normally.
Ken Thomases
2015-10-13 20:54:49 UTC
Permalink
Post by Jeremy Huddleston Sequoia
Thanks for all this feedback regarding the window placement issue. I'd really like to be able to reproduce the issue myself to verify that the proposed solution addresses the problem, but I am not seeing the issue on my machine.
For those of you reproducing, can you please fill in the following data?
I suggest you also ask for the Dock configuration: is it positioned on the bottom or one of the sides of the screen? Is it set to auto-hide or not.

Jeremy, have you tried with the Dock on the bottom and not auto-hiding?

Regards,
Ken
Jeremy Huddleston Sequoia
2015-10-13 22:36:40 UTC
Permalink
Post by Ken Thomases
Post by Jeremy Huddleston Sequoia
Thanks for all this feedback regarding the window placement issue. I'd really like to be able to reproduce the issue myself to verify that the proposed solution addresses the problem, but I am not seeing the issue on my machine.
For those of you reproducing, can you please fill in the following data?
I suggest you also ask for the Dock configuration: is it positioned on the bottom or one of the sides of the screen? Is it set to auto-hide or not.
Jeremy, have you tried with the Dock on the bottom and not auto-hiding?
Yep, that was it. I run with it on the right. I can reproduce it now. Unfortunately, it still reproduces with:

aquaMenuBarHeight = [[NSApp mainMenu] menuBarHeight];
#if ! __LP64__
if (!aquaMenuBarHeight) {
aquaMenuBarHeight = [NSMenuView menuBarHeight];
}
#endif
if (!aquaMenuBarHeight) {
NSScreen* primaryScreen = [[NSScreen screens] objectAtIndex:0];
aquaMenuBarHeight = NSHeight([primaryScreen frame]) - NSMaxY([primaryScreen visibleFrame]);
}

but at least I can reproduce it and should be able to get out an rc3 later this week.

--Jeremy
Tom Lane
2015-10-14 04:00:12 UTC
Permalink
Post by Jeremy Huddleston Sequoia
Post by Ken Thomases
Jeremy, have you tried with the Dock on the bottom and not auto-hiding?
Yep, that was it. I run with it on the right. I can reproduce it now.
FWIW, I installed rc2 this afternoon, while working in my usual work setup
with an external monitor (configured to appear above the internal display,
with the menu bar on the external monitor, dock on bottom, not
auto-hiding). Did not see any problem. But now after disconnecting the
external monitor, I *do* see the problem just as described: I can't get
X11 windows to use any of the top half-inch or so of the internal display.
Quitting and restarting XQuartz doesn't help that. So maybe
adding/removing external displays should be part of your thinking.

(BTW, I also notice that the program name, according to the menu bar item
just to the right of the Apple menu, is now "XQuartz" not "X11". Is that
intentional?)

(Running OSX 10.10.5 if that matters.)

regards, tom lane
Jeremy Huddleston Sequoia
2015-10-14 06:24:55 UTC
Permalink
Post by Tom Lane
Post by Jeremy Huddleston Sequoia
Post by Ken Thomases
Jeremy, have you tried with the Dock on the bottom and not auto-hiding?
Yep, that was it. I run with it on the right. I can reproduce it now.
FWIW, I installed rc2 this afternoon, while working in my usual work setup
with an external monitor (configured to appear above the internal display,
with the menu bar on the external monitor, dock on bottom, not
auto-hiding). Did not see any problem. But now after disconnecting the
external monitor, I *do* see the problem just as described: I can't get
X11 windows to use any of the top half-inch or so of the internal display.
Quitting and restarting XQuartz doesn't help that. So maybe
adding/removing external displays should be part of your thinking.
(BTW, I also notice that the program name, according to the menu bar item
just to the right of the Apple menu, is now "XQuartz" not "X11". Is that
intentional?)
Yes.
Post by Tom Lane
(Running OSX 10.10.5 if that matters.)
regards, tom lane
_______________________________________________
Xquartz-dev mailing list
https://lists.macosforge.org/mailman/listinfo/xquartz-dev
Tom Lane
2015-10-14 14:14:53 UTC
Permalink
Post by Tom Lane
(BTW, I also notice that the program name, according to the menu bar item
just to the right of the Apple menu, is now "XQuartz" not "X11". Is that
intentional?)
Yes.
OK, but it seems a little odd that you did not also s/X11/XQuartz/ in the
rest of the menus, particularly "About X11" and "Check for X11 Updates".

FWIW, rc3 does not show any menu bar height funnies for me while adding
and removing external monitor. So that fix looks good from here.

regards, tom lane
Jeremy Huddleston Sequoia
2015-10-14 15:55:28 UTC
Permalink
Post by Tom Lane
Post by Tom Lane
(BTW, I also notice that the program name, according to the menu bar item
just to the right of the Apple menu, is now "XQuartz" not "X11". Is that
intentional?)
Yes.
OK, but it seems a little odd that you did not also s/X11/XQuartz/ in the
rest of the menus, particularly "About X11" and "Check for X11 Updates".
True. I'll do the rest before the final release.

The existing change from X11 -> XQuartz was because I just deleted some localization files that were out of date, so the name went back to the value in Info.plist.
Post by Tom Lane
FWIW, rc3 does not show any menu bar height funnies for me while adding
and removing external monitor. So that fix looks good from here.
Good to hear these reports, thanks.
Post by Tom Lane
regards, tom lane
_______________________________________________
Xquartz-dev mailing list
https://lists.macosforge.org/mailman/listinfo/xquartz-dev
Jeremy Huddleston Sequoia
2015-10-14 07:34:10 UTC
Permalink
Post by Ken Thomases
Post by Ken Thomases
Post by Jeremy Huddleston Sequoia
Thanks for all this feedback regarding the window placement issue. I'd really like to be able to reproduce the issue myself to verify that the proposed solution addresses the problem, but I am not seeing the issue on my machine.
For those of you reproducing, can you please fill in the following data?
I suggest you also ask for the Dock configuration: is it positioned on the bottom or one of the sides of the screen? Is it set to auto-hide or not.
Jeremy, have you tried with the Dock on the bottom and not auto-hiding?
Actually, that does solve the issue. I was just testing the wrong build... sigh...

In any event, thanks for the help getting this turned around quickly, Ken.
Post by Ken Thomases
aquaMenuBarHeight = [[NSApp mainMenu] menuBarHeight];
#if ! __LP64__
if (!aquaMenuBarHeight) {
aquaMenuBarHeight = [NSMenuView menuBarHeight];
}
#endif
if (!aquaMenuBarHeight) {
NSScreen* primaryScreen = [[NSScreen screens] objectAtIndex:0];
aquaMenuBarHeight = NSHeight([primaryScreen frame]) - NSMaxY([primaryScreen visibleFrame]);
}
but at least I can reproduce it and should be able to get out an rc3 later this week.
--Jeremy
Loading...