[Xquartz-dev] Regression in 2.7.1_rc4: maximize/demaximize window is busted

[Jeremy Huddleston]

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 at 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 at 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 at 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 at lists.macosforge.org
>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>>> 
>>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>> 
> 
> 
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>