Re: Bugs in gui/back

[Fred Kiefer]

Hi Andreas,

great to see that you are still using GNUstep and actually now willing to use a 
more current version of it as well. Although still not the latest from git :-(

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.

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? 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. So it would be very 
easy to implement.
Re-layouting would happen on level of the content view. If this doesn’t happen 
for you something is really broken. Could you please provide the code you are 
using?

As for the bug in NSTabView I am looking forward to hear about that in more 
detail.
 
Cheers,
Fred
 

> Am 20.04.2018 um 17:07 schrieb Andreas Höschler <ahoesch@smartsoft.de>:
> 
> Hi all,
> 
> I just found ./gnustep-gui-0.25.1/Documentation/manual/theviewconcept.texi 
> and suppose that the problem is caused by the optimization mentioned in this 
> document. It seems critical calls (that MacOSX at least still performs) to 
> NSWindow::drawRect: are skipped now. 
> 
> Any hint where to look is greatly appreciated. I wold love to get the new 
> GNUstep tree working ...
> 
> Thanks in advance,
> 
>  Andreas
> 
> 
> 
> 
> On Apr 20, 2018, at 2:50 PM, Andreas Höschler wrote:
> 
>> I currently have a window with just one button and a spacer above and below 
>> it and am trying to resize the window vertically which works. However, 
>> 
>> NSWindow:
>> 
>>      - (void)setFrame:(NSRect)frameRect display:(BOOL)flag
>> 
>> is never called when I do this which is probably the reason why auto 
>> relayouting the content does not work. On MacOSX (same sources) I get a 
>> bunch of 
>> 
>> 2018-04-20 14:36:31.770 TabTest[8909:903] setFrame {{26, 282}, {97, 124}} 
>> display 1
>> 2018-04-20 14:36:31.780 TabTest[8909:903] setFrame {{26, 285}, {97, 121}} 
>> display 1
>> 2018-04-20 14:36:31.804 TabTest[8909:903] setFrame {{26, 287}, {97, 119}} 
>> display 1
>> 2018-04-20 14:36:31.831 TabTest[8909:903] setFrame {{26, 288}, {97, 118}} 
>> display 1
>> 2018-04-20 14:36:31.881 TabTest[8909:903] setFrame {{26, 289}, {97, 117}} 
>> display 1
>> 2018-04-20 14:36:31.931 TabTest[8909:903] setFrame {{26, 289}, {97, 117}} 
>> display 1
>> ...
>> 
>> calls when I vertically resize the window and the content is relayouted just 
>> fine!?
>> 
>> Any idea where to look from here? Which part in GNUstep is responsible for 
>> sending setFrame:display: to NSWindow when dragging the window larger and 
>> smaller?
>