[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bugs in gui/back
From: |
Andreas Höschler |
Subject: |
Re: Bugs in gui/back |
Date: |
Sat, 21 Apr 2018 16:43:59 +0200 |
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
- Bugs in gui/back, Andreas Höschler, 2018/04/20
- Re: Bugs in gui/back, Andreas Höschler, 2018/04/20
- Re: Bugs in gui/back, Andreas Höschler, 2018/04/20
- Re: Bugs in gui/back, Fred Kiefer, 2018/04/21
- Re: Bugs in gui/back, Fred Kiefer, 2018/04/22
- Re: Bugs in gui/back, Andreas Höschler, 2018/04/23
- Re: Bugs in gui/back, Fred Kiefer, 2018/04/23
- Re: Bugs in gui/back, Andreas Höschler, 2018/04/24
- Re: Bugs in gui/back, Ivan Vučica, 2018/04/24
- Re: Bugs in gui/back, Andreas Höschler, 2018/04/24
- Re: Bugs in gui/back, Liam Proven, 2018/04/24
- Re: Bugs in gui/back, Andreas Höschler, 2018/04/24