[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autoresizing in the case of negative flexible space (was Re: Pixel-a

From: Fred Kiefer
Subject: Re: autoresizing in the case of negative flexible space (was Re: Pixel-aligned autoresizing)
Date: Sat, 23 Jul 2011 15:44:12 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv: Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11

Thank you, I committed your change.

On 22.07.2011 21:27, Tim Schmielau wrote:
On 8 Jul 2011, at 22:56, Eric Wasylishen wrote:

On 2011-07-08, at 2:27 AM, Fred Kiefer wrote:

On 08.07.2011 09:34, Eric Wasylishen wrote:
Ok, great! I committed a slightly improved version of my rounding patch, and 
now both tests pass.

It looks like switching to the proportional autoresizing has cause a few 
glitches in gui; the colour pickers aren't showing up, and the font panel 
doesn't resize properly when stretched horizontally. Hopefully these will be 
easy to fix.

Thank you for spotting this. I noticed a strange problem with the NSBox test in 
GSTest and put in the check if options is greater than 0.0 to work around that. 
I hadn't noticed the other ones. Most likely there is a common cause (maybe 
related to negative coordinate?), we just need to find and fix it.

The good thing is that your change requires that people have to recompile all 
their libraries and applications. This should buy us time to fix the problem 
before they notice.

I found and fixed the main problem, which was not handling cases where the sum 
of the flexible space is 0. I added some more tests for this as well, which are 
all passing now.

I think NSFontPanel will need some manual tweaking so it resizes properly, 
maybe we can change it to use a GSHBox to hold the columns.

Hi Eric and Fred,

thanks for the great work you are doing! I'd like to suggest a little change 
though to fix a recently introduced incompatibility:

I have an app where at the bottom of a window there is a GUI element whose 
visibility can change. When the visibility changes, the height of the window is 
adjusted for the additional space needed. As the GUI element is supposed to 
appear at a fixed position from the top left corner of the window, only 
NSViewMinYMargin is set in the _autoresizingMask of the GUI element.

I believe this to be a common pattern under Cocoa, and the code worked well 
both on Mac OS and on GNUstep before the recent changes.

Since SVN revision 33482 however, the GUI element permanently disappears below 
the lower window border on the first time it is made invisible. This is because 
the window size adjustment makes the (now invisible) GUI element move to a 
negative Y position. Once the Y position is negative, the total flexibleSpace 
is negative, and the GUI element will not be moved back up again when the 
window becomes larger again.

This is a deviation from the behavior on Cocoa.  While I haven't investigated 
Cocoa's behavior more closely, it can be fixed by falling back to the old 
autoresizing behavior instead of just giving up when negative flexible space is 
encountered. The simple patch below achieves that.


Index: Source/NSView.m
--- Source/NSView.m     (revision 33608)
+++ Source/NSView.m     (working copy)
@@ -1970,7 +1970,7 @@
      flexibleSpace += oldContainerSize - oldContentPosition - oldContentSize;

-  if (flexibleSpace == 0.0)
+  if (flexibleSpace<= 0.0)
         * In this code path there is no flexible space so we divide
@@ -1994,7 +1994,7 @@
-  else if (flexibleSpace>  0.0)
+  else
         * In this code path we distribute the change proportionately

reply via email to

[Prev in Thread] Current Thread [Next in Thread]