Regression in 2.7.1_rc4: maximize/demaximize window is busted
Click the green maximize button of an X window. It grows to cover whole screen, good. Click it a second time; that should restore the window to its previous size, but actually nothing happens. rc1 did not have this bug AFAIR; can't say about rc2 because I didn't run it very long. regards, tom lane
Am 15.2.2012 um 19:19 schrieb Tom Lane:
Click the green maximize button of an X window. It grows to cover whole screen, good. Click it a second time; that should restore the window to its previous size, but actually nothing happens.
With Blackbox WM this works for me – and also with /usr/bin/quartz-wm version 1.1.0 on Snow Leopard 10.5.8. /opt/X11/bin/quartz-wm version 1.2.2 does not want to launch. What I see with /usr/bin/quartz-wm version 1.1.0 is that the windows are handled correctly, in that sense that the focus seems to stay in the active window and that their layering seems to stay correct. So the things that I keep reporting seem to be related to Blackbox WM... -- Greetings Pete There is no worse tyranny than to force a man to pay for what he does not want merely because you think it would be good for him. – Robert Heinlein
Peter Dyballa <Peter_Dyballa@Web.DE> writes:
Am 15.2.2012 um 19:19 schrieb Tom Lane:
Click the green maximize button of an X window. It grows to cover whole screen, good. Click it a second time; that should restore the window to its previous size, but actually nothing happens.
With Blackbox WM this works for me and also with /usr/bin/quartz-wm version 1.1.0 on Snow Leopard 10.5.8.
Sorry, I should have specified what I'm running this on ... up-to-date Lion. regards, tom lane
Yes, I see this for some windows, but not all of them. It looks like windows that have size increments (eg: xterm) that don't line up exactly with the maximal size are having issue. I think this is probably a regression from one of Ken's changes, so I'll let him take a first peek. I'm still busy with some other bits of quartz-wm and won't be able to look at this until those are all settled. --Jeremy On Feb 15, 2012, at 10:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Click the green maximize button of an X window. It grows to cover whole screen, good. Click it a second time; that should restore the window to its previous size, but actually nothing happens. rc1 did not have this bug AFAIR; can't say about rc2 because I didn't run it very long.
regards, tom lane
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Yes, it appears to have been 682660f84093f06f32515b1d01b649daa2e58fb1. The prior code sometimes tested for a maximized window by comparing the current frame with [_screen zoomed_rect:X11RectOrigin(_current_frame)] but other times compared it with [self validate_frame_rect:[_screen zoomed_rect:X11RectOrigin(_current_frame)]] The latter is more correct and takes WM size hints, like the resize increments, into account. My code standardized on the former, though. The old code was wrong in some cases, mine is wrong in all cases. So, the following patch seems to fix it: ==================== diff --git a/src/x-window.m b/src/x-window.m index 725471a..56d7bd2 100644 --- a/src/x-window.m +++ b/src/x-window.m @@ -2300,7 +2300,7 @@ - (void) do_toggle_shaded:(Time)timestamp - (BOOL) is_maximized { X11Rect r = [self intended_frame]; - return X11RectEqualToRect(r, [_screen zoomed_rect:X11RectOrigin(r)]); + return X11RectEqualToRect(r, [self validate_frame_rect:[_screen zoomed_rect:X11RectOrigin(r)]]); } - (void) do_zoom { ==================== The long story: My understanding is that quartz-wm's behavior is based on Cocoa's. NSWindow's -isZoomed method tests if the window's frame equals the zoomed frame computed for the window. So, any change of the window's frame potentially changes whether it is considered zoomed or not. Quartz-wm behaves similarly. There are two aspects of what "is considered zoomed" might mean. There's the method in the above patch, -is_maximized, in the quartz-wm code. That compares the current frame (well, "intended" frame) with a computed zoomed frame. Then, there's the question of whether quartz-wm puts the _NET_WM_STATE_MAXIMIZED_{HORZ,VERT} atoms in the window's _NET_WM_STATE property. My changes were intended to get the latter part to match the former. However, I also inadvertently made the computed zoomed frame not meet the is-it-zoomed test for windows with resize increments and, probably, a maximum size smaller than the screen. Quartz-wm would compute one zoomed frame for the window, set the frame to that, and then subsequently compare against a possibly different frame to determine if the window was zoomed. Sorry about that. Regards, Ken On Feb 15, 2012, at 9:05 PM, Jeremy Huddleston wrote:
Yes, I see this for some windows, but not all of them. It looks like windows that have size increments (eg: xterm) that don't line up exactly with the maximal size are having issue.
I think this is probably a regression from one of Ken's changes, so I'll let him take a first peek. I'm still busy with some other bits of quartz-wm and won't be able to look at this until those are all settled.
--Jeremy
On Feb 15, 2012, at 10:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Click the green maximize button of an X window. It grows to cover whole screen, good. Click it a second time; that should restore the window to its previous size, but actually nothing happens. rc1 did not have this bug AFAIR; can't say about rc2 because I didn't run it very long.
regards, tom lane
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Thanks Ken. I'm still up to my knees in reworking the dock support bits to be a bit more robust. I'll give this a whirl once all of that settles down. Thanks, Jeremy On Feb 16, 2012, at 3:25 PM, Ken Thomases <ken@codeweavers.com> wrote:
Yes, it appears to have been 682660f84093f06f32515b1d01b649daa2e58fb1.
The prior code sometimes tested for a maximized window by comparing the current frame with
[_screen zoomed_rect:X11RectOrigin(_current_frame)]
but other times compared it with
[self validate_frame_rect:[_screen zoomed_rect:X11RectOrigin(_current_frame)]]
The latter is more correct and takes WM size hints, like the resize increments, into account. My code standardized on the former, though. The old code was wrong in some cases, mine is wrong in all cases.
So, the following patch seems to fix it:
==================== diff --git a/src/x-window.m b/src/x-window.m index 725471a..56d7bd2 100644 --- a/src/x-window.m +++ b/src/x-window.m @@ -2300,7 +2300,7 @@ - (void) do_toggle_shaded:(Time)timestamp - (BOOL) is_maximized { X11Rect r = [self intended_frame]; - return X11RectEqualToRect(r, [_screen zoomed_rect:X11RectOrigin(r)]); + return X11RectEqualToRect(r, [self validate_frame_rect:[_screen zoomed_rect:X11RectOrigin(r)]]); }
- (void) do_zoom {
====================
The long story:
My understanding is that quartz-wm's behavior is based on Cocoa's. NSWindow's -isZoomed method tests if the window's frame equals the zoomed frame computed for the window. So, any change of the window's frame potentially changes whether it is considered zoomed or not. Quartz-wm behaves similarly.
There are two aspects of what "is considered zoomed" might mean. There's the method in the above patch, -is_maximized, in the quartz-wm code. That compares the current frame (well, "intended" frame) with a computed zoomed frame. Then, there's the question of whether quartz-wm puts the _NET_WM_STATE_MAXIMIZED_{HORZ,VERT} atoms in the window's _NET_WM_STATE property.
My changes were intended to get the latter part to match the former.
However, I also inadvertently made the computed zoomed frame not meet the is-it-zoomed test for windows with resize increments and, probably, a maximum size smaller than the screen. Quartz-wm would compute one zoomed frame for the window, set the frame to that, and then subsequently compare against a possibly different frame to determine if the window was zoomed.
Sorry about that.
Regards, Ken
On Feb 15, 2012, at 9:05 PM, Jeremy Huddleston wrote:
Yes, I see this for some windows, but not all of them. It looks like windows that have size increments (eg: xterm) that don't line up exactly with the maximal size are having issue.
I think this is probably a regression from one of Ken's changes, so I'll let him take a first peek. I'm still busy with some other bits of quartz-wm and won't be able to look at this until those are all settled.
--Jeremy
On Feb 15, 2012, at 10:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Click the green maximize button of an X window. It grows to cover whole screen, good. Click it a second time; that should restore the window to its previous size, but actually nothing happens. rc1 did not have this bug AFAIR; can't say about rc2 because I didn't run it very long.
regards, tom lane
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
It doesn't look like this fixes the bug I thought it might… when a Wine program starts out in a maximized state, often the actual Windows program looks normal but the quartz-wm window is fully stretch out with the contents small in a normal window size, with the rest of the actual maximized window just white. Pressing the zoom button a couple of times, or stretching the window automatically fixes the issue, it just doesn't start up right. I have not been able to reproduce this on all Wine programs, only some… I thought it might be a bug with WIne, but… it doesn't happen with quartz-wm 1.1.1 (I had handy to test with) or if Wine isn't letting the window manager decorate the windows. I thought this error was maybe something to do with it, so I built the latest git with this patch and the problem still appears. Is it related, or should I enter a new bug report? On Feb 16, 2012, at 6:33 PM, Jeremy Huddleston wrote:
Thanks Ken.
I'm still up to my knees in reworking the dock support bits to be a bit more robust. I'll give this a whirl once all of that settles down.
Thanks, Jeremy
On Feb 16, 2012, at 3:25 PM, Ken Thomases <ken@codeweavers.com> wrote:
Yes, it appears to have been 682660f84093f06f32515b1d01b649daa2e58fb1.
The prior code sometimes tested for a maximized window by comparing the current frame with
[_screen zoomed_rect:X11RectOrigin(_current_frame)]
but other times compared it with
[self validate_frame_rect:[_screen zoomed_rect:X11RectOrigin(_current_frame)]]
The latter is more correct and takes WM size hints, like the resize increments, into account. My code standardized on the former, though. The old code was wrong in some cases, mine is wrong in all cases.
So, the following patch seems to fix it:
==================== diff --git a/src/x-window.m b/src/x-window.m index 725471a..56d7bd2 100644 --- a/src/x-window.m +++ b/src/x-window.m @@ -2300,7 +2300,7 @@ - (void) do_toggle_shaded:(Time)timestamp - (BOOL) is_maximized { X11Rect r = [self intended_frame]; - return X11RectEqualToRect(r, [_screen zoomed_rect:X11RectOrigin(r)]); + return X11RectEqualToRect(r, [self validate_frame_rect:[_screen zoomed_rect:X11RectOrigin(r)]]); }
- (void) do_zoom {
====================
The long story:
My understanding is that quartz-wm's behavior is based on Cocoa's. NSWindow's -isZoomed method tests if the window's frame equals the zoomed frame computed for the window. So, any change of the window's frame potentially changes whether it is considered zoomed or not. Quartz-wm behaves similarly.
There are two aspects of what "is considered zoomed" might mean. There's the method in the above patch, -is_maximized, in the quartz-wm code. That compares the current frame (well, "intended" frame) with a computed zoomed frame. Then, there's the question of whether quartz-wm puts the _NET_WM_STATE_MAXIMIZED_{HORZ,VERT} atoms in the window's _NET_WM_STATE property.
My changes were intended to get the latter part to match the former.
However, I also inadvertently made the computed zoomed frame not meet the is-it-zoomed test for windows with resize increments and, probably, a maximum size smaller than the screen. Quartz-wm would compute one zoomed frame for the window, set the frame to that, and then subsequently compare against a possibly different frame to determine if the window was zoomed.
Sorry about that.
Regards, Ken
On Feb 15, 2012, at 9:05 PM, Jeremy Huddleston wrote:
Yes, I see this for some windows, but not all of them. It looks like windows that have size increments (eg: xterm) that don't line up exactly with the maximal size are having issue.
I think this is probably a regression from one of Ken's changes, so I'll let him take a first peek. I'm still busy with some other bits of quartz-wm and won't be able to look at this until those are all settled.
--Jeremy
On Feb 15, 2012, at 10:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Click the green maximize button of an X window. It grows to cover whole screen, good. Click it a second time; that should restore the window to its previous size, but actually nothing happens. rc1 did not have this bug AFAIR; can't say about rc2 because I didn't run it very long.
regards, tom lane
_______________________________________________ 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
Please do. Also note that quartz-wm is OSS, so if you could bisect to find the issue that would help. --Jeremy On Feb 17, 2012, at 7:27 AM, doh123 <doh123@doh123.com> wrote:
It doesn't look like this fixes the bug I thought it might… when a Wine program starts out in a maximized state, often the actual Windows program looks normal but the quartz-wm window is fully stretch out with the contents small in a normal window size, with the rest of the actual maximized window just white. Pressing the zoom button a couple of times, or stretching the window automatically fixes the issue, it just doesn't start up right. I have not been able to reproduce this on all Wine programs, only some…
I thought it might be a bug with WIne, but… it doesn't happen with quartz-wm 1.1.1 (I had handy to test with) or if Wine isn't letting the window manager decorate the windows. I thought this error was maybe something to do with it, so I built the latest git with this patch and the problem still appears.
Is it related, or should I enter a new bug report?
On Feb 16, 2012, at 6:33 PM, Jeremy Huddleston wrote:
Thanks Ken.
I'm still up to my knees in reworking the dock support bits to be a bit more robust. I'll give this a whirl once all of that settles down.
Thanks, Jeremy
On Feb 16, 2012, at 3:25 PM, Ken Thomases <ken@codeweavers.com> wrote:
Yes, it appears to have been 682660f84093f06f32515b1d01b649daa2e58fb1.
The prior code sometimes tested for a maximized window by comparing the current frame with
[_screen zoomed_rect:X11RectOrigin(_current_frame)]
but other times compared it with
[self validate_frame_rect:[_screen zoomed_rect:X11RectOrigin(_current_frame)]]
The latter is more correct and takes WM size hints, like the resize increments, into account. My code standardized on the former, though. The old code was wrong in some cases, mine is wrong in all cases.
So, the following patch seems to fix it:
==================== diff --git a/src/x-window.m b/src/x-window.m index 725471a..56d7bd2 100644 --- a/src/x-window.m +++ b/src/x-window.m @@ -2300,7 +2300,7 @@ - (void) do_toggle_shaded:(Time)timestamp - (BOOL) is_maximized { X11Rect r = [self intended_frame]; - return X11RectEqualToRect(r, [_screen zoomed_rect:X11RectOrigin(r)]); + return X11RectEqualToRect(r, [self validate_frame_rect:[_screen zoomed_rect:X11RectOrigin(r)]]); }
- (void) do_zoom {
====================
The long story:
My understanding is that quartz-wm's behavior is based on Cocoa's. NSWindow's -isZoomed method tests if the window's frame equals the zoomed frame computed for the window. So, any change of the window's frame potentially changes whether it is considered zoomed or not. Quartz-wm behaves similarly.
There are two aspects of what "is considered zoomed" might mean. There's the method in the above patch, -is_maximized, in the quartz-wm code. That compares the current frame (well, "intended" frame) with a computed zoomed frame. Then, there's the question of whether quartz-wm puts the _NET_WM_STATE_MAXIMIZED_{HORZ,VERT} atoms in the window's _NET_WM_STATE property.
My changes were intended to get the latter part to match the former.
However, I also inadvertently made the computed zoomed frame not meet the is-it-zoomed test for windows with resize increments and, probably, a maximum size smaller than the screen. Quartz-wm would compute one zoomed frame for the window, set the frame to that, and then subsequently compare against a possibly different frame to determine if the window was zoomed.
Sorry about that.
Regards, Ken
On Feb 15, 2012, at 9:05 PM, Jeremy Huddleston wrote:
Yes, I see this for some windows, but not all of them. It looks like windows that have size increments (eg: xterm) that don't line up exactly with the maximal size are having issue.
I think this is probably a regression from one of Ken's changes, so I'll let him take a first peek. I'm still busy with some other bits of quartz-wm and won't be able to look at this until those are all settled.
--Jeremy
On Feb 15, 2012, at 10:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Click the green maximize button of an X window. It grows to cover whole screen, good. Click it a second time; that should restore the window to its previous size, but actually nothing happens. rc1 did not have this bug AFAIR; can't say about rc2 because I didn't run it very long.
regards, tom lane
_______________________________________________ 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
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Pushed to master and 1.2 branch. Thanks, Jeremy On Feb 16, 2012, at 3:25 PM, Ken Thomases <ken@codeweavers.com> wrote:
Yes, it appears to have been 682660f84093f06f32515b1d01b649daa2e58fb1.
The prior code sometimes tested for a maximized window by comparing the current frame with
[_screen zoomed_rect:X11RectOrigin(_current_frame)]
but other times compared it with
[self validate_frame_rect:[_screen zoomed_rect:X11RectOrigin(_current_frame)]]
The latter is more correct and takes WM size hints, like the resize increments, into account. My code standardized on the former, though. The old code was wrong in some cases, mine is wrong in all cases.
So, the following patch seems to fix it:
==================== diff --git a/src/x-window.m b/src/x-window.m index 725471a..56d7bd2 100644 --- a/src/x-window.m +++ b/src/x-window.m @@ -2300,7 +2300,7 @@ - (void) do_toggle_shaded:(Time)timestamp - (BOOL) is_maximized { X11Rect r = [self intended_frame]; - return X11RectEqualToRect(r, [_screen zoomed_rect:X11RectOrigin(r)]); + return X11RectEqualToRect(r, [self validate_frame_rect:[_screen zoomed_rect:X11RectOrigin(r)]]); }
- (void) do_zoom {
====================
The long story:
My understanding is that quartz-wm's behavior is based on Cocoa's. NSWindow's -isZoomed method tests if the window's frame equals the zoomed frame computed for the window. So, any change of the window's frame potentially changes whether it is considered zoomed or not. Quartz-wm behaves similarly.
There are two aspects of what "is considered zoomed" might mean. There's the method in the above patch, -is_maximized, in the quartz-wm code. That compares the current frame (well, "intended" frame) with a computed zoomed frame. Then, there's the question of whether quartz-wm puts the _NET_WM_STATE_MAXIMIZED_{HORZ,VERT} atoms in the window's _NET_WM_STATE property.
My changes were intended to get the latter part to match the former.
However, I also inadvertently made the computed zoomed frame not meet the is-it-zoomed test for windows with resize increments and, probably, a maximum size smaller than the screen. Quartz-wm would compute one zoomed frame for the window, set the frame to that, and then subsequently compare against a possibly different frame to determine if the window was zoomed.
Sorry about that.
Regards, Ken
On Feb 15, 2012, at 9:05 PM, Jeremy Huddleston wrote:
Yes, I see this for some windows, but not all of them. It looks like windows that have size increments (eg: xterm) that don't line up exactly with the maximal size are having issue.
I think this is probably a regression from one of Ken's changes, so I'll let him take a first peek. I'm still busy with some other bits of quartz-wm and won't be able to look at this until those are all settled.
--Jeremy
On Feb 15, 2012, at 10:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Click the green maximize button of an X window. It grows to cover whole screen, good. Click it a second time; that should restore the window to its previous size, but actually nothing happens. rc1 did not have this bug AFAIR; can't say about rc2 because I didn't run it very long.
regards, tom lane
_______________________________________________ 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
participants (5)
-
doh123
-
Jeremy Huddleston
-
Ken Thomases
-
Peter Dyballa
-
Tom Lane