Re: Bugs in gui/back

[Fred Kiefer]

Am 21.04.2018 um 16:43 schrieb Andreas Höschler:
>> 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?

Thank you for providing this additional information. I can now see what
is going wrong we just need to find out together why :-)

To give you a bit of background on what is going on here:
In Cocoa an NSWindow has a content rectangle and a frame rectangle. The
first is the area that the application draws into whereas the second is
the whole window including decorations. This difference gets handled by
a specific view, Apple calls it the borderview while GNUstep uses the
term windowview, which sits inside the window and has the content view
as its subview. In GNUstep this gets implemented by the two sub classes
of GSWindowDecorationView:
- GSBackendWindowDecorationView, here the window decoration gets handled
by the window system itself
- GSStandardWindowDecorationView, here GNUstep draws all the window
decoration.

You may switch between these two implementations by setting the default
value for the key GSBackHandlesWindowDecorations.

What happens in your case is that GNUstep and the window system disagree
about the size of the window that is being displayed. How could that
happen? When a window gets created we cannot ask the window system about
the amount of space it will be using for the window decoration. So
GNUstep pre-computes the decorations size for all possible window types
in advance and uses these values when ever a window gets created. Now in
your case these values seem to be wrong and when the window gets resized
we get a different number for the height then expected.

It is easy to inspect these numbers as GNUstep stores them on the root
window as properties.
  xprop -root _GNUSTEP_FRAME_OFFSETS

Every group of four values belongs to a window style. If you see zeros
or negative values here this might point to invalid numbers. In that
case you should remove these values with the following command:
xprop -root _GNUSTEP_FRAME_OFFSETS

And start up a GNUstep applications, which will then try to recompute
the values. If we are lucky this will already remove the issue. If it
persists I will have to investigate a bit more what is going on.

Hope this helps,
Fred