Thu 17 Oct 2013 10:46:14 PM UTC, comment #3:
"the autoresize mask should only come into play if the view is resized, and since the NSTabView containing the items is not resizeable, this should not have any effect. "
The autoresizing mask comes into play because GNUstep doesn't assign the same size to the NSTabView subviews as Cocoa. i.e. the theme metrics of the default theme don't match Cocoa's, so it's as if you are resizing the tab view slightly.
So for now, you have to make the tab contents look good when resized, even if you don't want the tabview itself to be resizable.
With this in mind, current gnustep trunk is doing everything correctly as far as I can see. e.g. the "objectives" box on tab 1 being shifted up, "enemies / rounds / difficulty" being shifted up on tab 2, and "enable core breaches" being shifted up on tab 4 are all expected: If you open the xib in Xcode and make the window and outer tabview resizable, and expand the window slightly to simulate the difference in tabview metrics between the GS theme and Cocoa, you get the same results.
On tab 2, the highscores tabview touching the "space ship" box is a separate issue: we draw right to the edge of the frame of a tab view, whereas cocoa leaves a lot of empty space.
So to sum up, there are two separate problems here:
- difference between view frame and the visible border of the view for some NSView subclasses on GNUstep and Cocoa (the layout rect vs frame problem.) Cocoa leaves empty space between the control's visible border and the frame, whereas GNUstep draws right up to the frame. Fred, Quentin and I are having a discussion about how to solve this problem right now.
- even if the first problem were fixed, we have the problem of different amounts of space in Cocoa and GNUstep between the frame of a composite view like NSTabView, NSBox, etc. and the subviews. This is why the autoresizing masks of things inside the tabs matters. The only fix for this is adjusting the default theme to have the same metrics as Cocoa.
Fred: as far as I can see, we can disable the hack that changes the subview autoresizing mask to NSWidthSizable|NSHeightSizable. Although, I don't see how that should have any effect, since immediately after doing that we call setFrame on the subview.
|