Was that behaving right on the primary display using quartz-wm from 2.3.2_rc2? I don't see how my changes here should cause that particular problem since all I've changed is the code that returns the rect for the display containing a given point (completely outside the code dealing with a particular window)... I imagine that could easily be an issue that I caused between 2.3.1 and 2.3.2_rc2, but I'd like to make sure I didn't overlook something... On Dec 4, 2008, at 08:20, Brian Bender wrote:

Hi Jeremy,

One old oddness is gone, but a new one has taken its place.

The old "display stickiness" seems to be fixed (once you zoomed it to one display, if you restored its size and moved it to the other display, it would still always zoom back to the first) -- is that the behavior you were chasing?

Anyway, now with this version, when I zoom a window that has a fixed size (vncviewer, rdesktop) that's smaller than the display, the X11 window maximizes to the entire display size rather than the size of the content (which can't expand), leaving blank border around the content. Before, it would zoom the window to the size of the content (if possible to fit, else to the display size with scroll-bars), and position it at 0,0 on the display that the close/min/zoom buttons were on when they were clicked. (cue the Mac vs. Windows debate about maximize vs. zoom <g>)

Thanks,

-- Brian

On Thu, Dec 4, 2008 at 2:58 AM, Jeremy Huddleston jeremyhu-at-apple.com |Xquartz-dev/personal| <...> wrote:

...

I think I've fixed the bad behavior with the zoom button when dealing with more than one monitor. I've tested it with a few configurations, but if you use multiple monitors, I'd like to get feedback on whether or not the zoom/maximize button is behaving correctly in case there's a configuration my tests didn't cover.

Thanks.

curl -LO http://people.freedesktop.org/~jeremyhu/quartz-wm-20081203.bz2 bunzip2 quartz-wm-20081203.bz2 sudo cp quartz-wm-20081203 /usr/bin/quartz-wm

--Jeremy

_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev

_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev

On Dec 4, 2008, at 13:52, Brian Bender wrote:

Looks like the change was before 2.3.2_rc2.

I just rolled back to the quartz-wm that was in rc2, and it behaves the same as your latest build -- it maximizes to the screen's full size instead of zooming to the client's size.

- Brian

Yep, thanks for checking that. Can you give this a try. It adds a check to validate the window size when we do the "maximize". http://people.freedesktop.org/~jeremyhu/quartz-wm-20081204.1.bz2 That should take care of all the quartz-wm regressions that I've been told about. --Jeremy

On Thu, 4 Dec 2008, Brian Bender - zt4q4o402@sneakemail.com wrote:

The old "display stickiness" seems to be fixed (once you zoomed it to one display, if you restored its size and moved it to the other display, it would still always zoom back to the first) -- is that the behavior you were chasing?

I saw what you describe above as well at some point. It appears fixed now. There has been a lot of oddity I have seen in the last two versions. At one point clicking on zoom would make a window larger than my largest display. That seemed to get fixed but was replaced by zoom only working at all on the primary screen. These three things seem to have been fixed, yippie! mzs

On Dec 4, 2008, at 08:28, Viv Kendon wrote:

I've just installed it [quartz-wm-20081203], and the maximise button does more or less sensible things from my point of view, it maximises to fill the monitor that contains the top left corner of the window (I should mention I don't use really use these buttons at all, because I almost never want my windows maximised. What I do want is to maximise them vertically without changing the width, and I have fvwm programmed to do that with its equivalent buttons. But that's waiting for when full screen gets a bit more work on it...)

I did just notice there is a slightly odd effect if I try to move a window to the very top of the secondary monitor (which is to the right of the primary in my case, and exactly the same height). If I move the mouse to the very top, the window gets dropped a menu bar width below the top. But if I'm careful not to get the mouse right at the top, I can correctly position a window right at the top. If the window is partly on both monitors (so part of it is going behind the menu bar), the jumping down happens when the window reaches the very top, regardless of whether the mouse is at the top or not. Not a show stopper, but something to fix when you are next wandering around that bit of the code.

Yeah, I think I fixed that just now. It's an artifact of the 3 different coordinate system's we're jumping between (NS* has an inverted Y compared to X11) and the ownership rule for region boundaries in computer graphics. Boring details aside, I think this should fix that particular problem: http://people.freedesktop.org/~jeremyhu/quartz-wm-20081204.bz2

BTW, when I downloaded rc2, I noticed there is Xquartz-1.4.2- apple26.bz2 in the available files. Are we supposed to be playing with this? The one I have installed from rc2 says it is xorg-server 1.4.2-apple25. I did try installing the -apple26 one, but it does very strange things with window placement, so I rapidly uninstalled it.

Really? How so? There's actually not much difference between the two versions. Just; 6 days XQuartz: Added option to enable/disable test extensions Jeremy Huddleston 4 -3/+17 6 days XQuartz: Avoid some warning messages being spewed to system.log by AppKit Jeremy Huddleston 1 -1/+3 6 days XQuarz: Setup our PATH and PWD earlier, so our initial client benefits from i... Jeremy Huddleston 3 -16/+29 8 days XQuartz: Fix dead-acute on Greek keyboards Jeremy Huddleston 1 -1/+2 8 days XQuartz: Fix Czech keyboard dead-acute

On Thu, 4 Dec 2008, Viv Kendon wrote:

On Thu, 4 Dec 2008, Jeremy Huddleston wrote:

...

On Dec 4, 2008, at 08:28, Viv Kendon wrote:

...

I've just installed it [quartz-wm-20081203], and the maximise button does <snip> I did just notice there is a slightly odd effect if I try to move a window to the very top of the secondary monitor (which is to the right of the <snip> Yeah, I think I fixed that just now. It's an artifact of the 3 different coordinate system's we're jumping between (NS* has an inverted Y compared to X11) and the ownership rule for region boundaries in computer graphics. Boring details aside, I think this should fix that particular problem:

http://people.freedesktop.org/~jeremyhu/quartz-wm-20081204.bz2

I picked up quartz-wm-20081204.1.bz2 and it is indeed fixed -- thanks! I just noticed that after maximising an xterm you can't unmaximise it again. I presume this is a problem with xterm, since maximising works as expected for other windows?

...

...

BTW, when I downloaded rc2, I noticed there is Xquartz-1.4.2-apple26.bz2 in the available files. Are we supposed to be playing with this? The one I have installed from rc2 says it is xorg-server 1.4.2-apple25. I did try installing the -apple26 one, but it does very strange things with window placement, so I rapidly uninstalled it.

Really? How so? There's actually not much difference between the two versions. Just;

Well, windows opened behind rather than on top, two at once jumped sideways by half their width to the left partly off screen, focus got stuck on the wrong windows (the one behind rather than the one the mouse was actually over...) This was all before I dropped in quartz-wm-20081203 though. I'll give it another go tomorrow on the same machine, with quartz-wm-20081204 in place as well. It could just have been an instance of "the first relaunch of X11 after an upgrade has a strop that isn't reproducible", that several others have also reported experiencing.

I'm think I'm now running this version of Xquartz with no problems: ls -l Xquartz* 56 -rwxr-xr-x 1 root wheel 53484 Dec 4 13:47 Xquartz* 40 -rwxr-xr-x 1 root wheel 39200 Nov 27 06:47 Xquartz-1.4.2-apple25* I can only tell it is apple26 because it is bigger, it still reports itself as being apple25 when I ask "about X11". I just remembered it actually crashed when I ran it the first time, crash report attached. I was trying to resize the panes in the "Customize" bit of the X11 Applications menu when it died. I've just done the same thing successfully with no crash this time. -- Viv ________________________________________________ Dr Viv Kendon http://quantum.leeds.ac.uk/~viv tel: +44 113 343 4864 Physics and Astronomy Quantum Information Group University of Leeds

...

ls -l Xquartz* 56 -rwxr-xr-x 1 root wheel 53484 Dec 4 13:47 Xquartz* 40 -rwxr-xr-x 1 root wheel 39200 Nov 27 06:47 Xquartz-1.4.2-apple25*

I can only tell it is apple26 because it is bigger, it still reports itself as being apple25 when I ask "about X11".

Really? I see "XQuartz 2.3.2 (xorg-server 1.4.2-apple26)"

BTW, you can also just run: /usr/X11/bin/X -version I wonder if you replaced the /usr/X11/bin/X symlink with the 1.4.2- apple21 binary at some point...

On Fri, Dec 5, 2008 at 3:37 PM, Jeremy Huddleston jeremyhu-at-apple.com |Xquartz-dev/personal| <...> wrote:

No, that's one more hint (size increments) that we need to be careful about.

This should fix it: http://people.freedesktop.org/~jeremyhu/quartz-wm-20081205.bz2

That should also allow you to "unmaximize" vncviewer, etc...

Hi Jeremy, I just noticed one more thing with the zoom/maximize stuff: If I try to zoom a window that's _bigger_ than my display, it maximizes the window offscreen rather than fitting it to the display and adding scrollbars. - Brian

On Fri, Dec 5, 2008 at 5:31 PM, Jeremy Huddleston jeremyhu-at-apple.com |Xquartz-dev/personal| <...> wrote:

...

If I try to zoom a window that's _bigger_ than my display, it maximizes the window offscreen rather than fitting it to the display and adding scrollbars.

I'm guessing that if you hit the zoom button a second time, it will resize it to the expected maximize size, right?

That should be fixed with quartz-wm-20081205.

No, that was _with_ quartz-wm-20081205. And it happens both with a big, dual-screen workspace and with just my built-in display by itself (I restarted X11.app after I disconnected the external display), so it's not just a case of being fooled by the bigger total workspace... Thanks, - Brian

On Fri, Dec 5, 2008 at 7:00 PM, Jeremy Huddleston jeremyhu-at-apple.com |Xquartz-dev/personal| <...> wrote:

You sure?

~ $ openssl sha1 /usr/bin/quartz-wm SHA1(/usr/bin/quartz-wm)= ff60bace6026a128333cb5752478da65232b0ede

Yep, had the right file.

I also tried with a vnc server that was larger than my display:

~ $ vncserver -geometry 2048x2048

and that works as expected.

I just tried the same thing with vncviewer, and it works right for me as well. It looks like it's just rdesktop that wasn't resizing to the desktop when it's workspace is bigger. [...pause...] I just tried the same thing with a huge rdesktop window on the family iMac downstairs (running the stock 1.3.0-apple22 server as supplied by Software Update), and it behaves the same way. Apparently rdesktop windows just aren't resizable, though I could have sworn that they were. Sorry about that. You've addressed everything that I'd been able to find, then. Thanks again for your (and the others') work, Jeremy. X11 is still an important part of at least some people's (certainly mine!) workflow on OS X. - Brian