Window positions when adding/removing monitors on 2.6.0
Both 2.6.0beta2 and rc1 seem to have a rather severe regression from 2.5.x in terms of what happens when the screen dimensions change. I go on a daily basis between using my MBP standalone and using it with an external monitor plugged in. I arrange the external monitor to be "above" the internal screen so that I have a twice-as-high screen workspace (internal and external are both 1440x900). In the past, when I attach the external monitor, X11 windows automatically move up onto the external screen, and when I remove it, whatever was on the external screen shifts back down to the internal. In both cases, the windows are effectively keeping the same positions in the global coordinate space measured from upper left; you could argue whether that's the most useful definition, but it works well for me. As of 2.6.0, this still works for enlarging the screen, but it goes completely wacko for shrinking the screen: the windows that had been on the external monitor disappear altogether. I find that I have to sleep and re-wake the laptop another time to get them to show up at all, and when they do show up, they all get smashed to the internal screen's UL corner, rather than keeping their relative positions. This is really a pretty nasty usability degradation from 2.5.3. I was hoping for smarter management of screen size changes, not worse management. regards, tom lane
On Dec 10, 2010, at 17:32, Tom Lane wrote:
Both 2.6.0beta2 and rc1 seem to have a rather severe regression from 2.5.x in terms of what happens when the screen dimensions change.
I go on a daily basis between using my MBP standalone and using it with an external monitor plugged in. I arrange the external monitor to be "above" the internal screen so that I have a twice-as-high screen workspace (internal and external are both 1440x900). In the past, when I attach the external monitor, X11 windows automatically move up onto the external screen, and when I remove it, whatever was on the external screen shifts back down to the internal. In both cases, the windows are effectively keeping the same positions in the global coordinate space measured from upper left; you could argue whether that's the most useful definition, but it works well for me.
Right. That's actually a bug. They should stay in the same location like NSWindows do.
As of 2.6.0, this still works for enlarging the screen, but it goes completely wacko for shrinking the screen: the windows that had been on the external monitor disappear altogether.
Really? That's odd. There was a window location validation bug intorduced in 2.5.0 (http://xquartz.macosforge.org/trac/ticket/372), but quartz-wm hasn't changed (enough to mention) between 2.5.3 and 2.6.0.
I find that I have to sleep and re-wake the laptop another time to get them to show up at all, and when they do show up, they all get smashed to the internal screen's UL corner, rather than keeping their relative positions.
This is really a pretty nasty usability degradation from 2.5.3. I was hoping for smarter management of screen size changes, not worse management.
Can you please isolate if this is an issue due to quartz-wm or the server. Please try using the SL quartz-wm at /usr/bin/quartz-wm rather than the newer /opt/X11/bin/quartz-wm. You mention that you see this in 2.6.0_beta2. Was this in beta1? alpha2? alpha1? Narrowing down where this bug came in will help find it. Please open a ticket at http://xquartz.macosforge.org
participants (2)
-
Jeremy Huddleston
-
Tom Lane