Re: Bugs in gui/back

[Andreas Höschler]

Hi Fred,

> great to see that you are still using GNUstep and actually now willing to use 
> a more current version of it as well.

Yes, I still use GNUstep (and MacOSX) on a daily basis. Our software stack is 
supposed to run on both platforms and has done so for at least 15 years now, 
including all our in-house dev tools. 

> And your observation is correct at the moment GNUstep gui isn’t calling 
> setFrame:display: when resizing a window with operation system mechanisms. 
> This is due to the fact that we could get a circular calling hierarchy that 
> way and we tried hard to protect from that. If this really affects your 
> application we could try to adjust the behaviour, but we need to be very 
> careful here.

OK!

Both, MacOSX and the ancient GNUstep I had been using until now do call 
NSWindow::drawRect:display: when the window is resized by the user. But I do 
not depend on that. I actually subclass NSWindow in my apps but do not 
overwrite NSWindow::drawRect:display: (just checked). 

I instead expect setFrame: and/or setFrameSize: to be called on the 
contentView. The contentView is either a VBox or a HBox. These two classes do 
the auto relayouting of the widgets in these methods.

Further analysis showed that I get setFrame: and setFrameSize: calls on the 
contentView under MacOSX and calls to only setFrame: on the new GNUstep which 
would be sufficient for my purposes if the passed NSRect were correct. But that 
seems to be not the case under GNUstep. Please see the following log:

Starting the app gives

2018-04-21 16:28:48.272 TabTest[4371:4371] Setting contentView <GSVBox: 
0x2c51068>
2018-04-21 16:28:48.272 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 53} - <GSVBox: 0x2c51068>

2018-04-21 16:28:48.276 TabTest[4371:4371] setFrame {x = 140; y = 574; width = 
85; height = 114} display 0
2018-04-21 16:28:48.277 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 114} - <GSVBox: 0x2c51068>
2018-04-21 16:28:48.277 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 114} - <GSVBox: 0x2c51068>

2018-04-21 16:28:48.278 TabTest[4371:4371] setFrame {x = 140; y = 574; width = 
85; height = 114} display 0
2018-04-21 16:28:48.280 TabTest[4371:4371] setFrame {x = 140; y = 574; width = 
85; height = 114} display 0

and shows the button perfectly centered. I wonder why the first 
NSWindow::drawRect:display: call is followed by GSVBox::setFrame: but the other 
two calls aren't!? That is probably due to the mentioned optimization.

But see what happens if I touch the window corner with the mouse and start to 
drag (not even yet a mm).

2018-04-21 16:28:54.052 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 147} - <GSVBox: 0x2c51068>
2018-04-21 16:28:54.053 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 147} - <GSVBox: 0x2c51068>
2018-04-21 16:28:54.156 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 148} - <GSVBox: 0x2c51068>
2018-04-21 16:28:54.156 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 148} - <GSVBox: 0x2c51068>

I get setFrame:: calls on the GSVBox (contentView of the window) but with a 
wrong height. The height should still be roughly 114 as I have not 
significantly resized the window yet. But I get height = 148. Could these 
additional 34 pixel be the height of the windows title bar? Something is simply 
calculated wrong here for whatever reason (height of the window's title 
omitted).

Does this ring any bells?

> What surprise me is that you actually noticed this implementation detail. 
> Normally you wouldn’t subclass NSWindow and only in this case the behaviour 
> is observable. Could you please explain what you are doing and why?

See above.

> Already for the content view the behaviour should be the same as on Cocoa. I 
> also wasn’t aware that there is an NSWindow drawRect: method. Are you really 
> sure about this? If so, this should just call the content view method.

This seems to be the case but with a falsely calculated height in the passed 
NSRect.

> So it would be very easy to implement.
> Re-layouting would happen on level of the content view.

That's how it is implemented.

Thanks a lot for looking into this!!

 Andreas