Bugs in gui/back

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Bugs in gui/back

Andreas Höschler
Hi all,

after 10 years of successfully using an ancient GNUstep tree I have upgraded to

        gnustep-back-0.25.1.tar.gz  
        gnustep-gui-0.25.1.tar.gz
        gnustep-base-1.25.0.tar.gz  
        gnustep-make-2.7.0.tar.gz

and am testing it on Ubuntu 16.04. The sources built without issues. That's good.

However, I seem to be far away from getting anything from our software stack to run on the current GNUstep sources. I have already fixed an issue with NSTabView (will report/summarize later) but had to go back to zero with the most simple test app to test out gui and back.

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? I guess this is more a back issue than gui!? If I remember correctly

        tar xvfz gnustep-back-0.25.1.tar.gz
        cd gnustep-back-0.25.1
        ./configure
        make
        make install
        cd ..

chose cairo on the current Ubuntu machine!? I used to have lib-art under Solaris!?

Thanks a lot,

 Andreas




_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Andreas Höschler
Hi all,

I just installed back with xlib and get the same behaviour. So it's either in gui or back!?

Hints greatly appreciated!!

Thanks,
 
   Andreas



after 10 years of successfully using an ancient GNUstep tree I have upgraded to

gnustep-back-0.25.1.tar.gz  
gnustep-gui-0.25.1.tar.gz
gnustep-base-1.25.0.tar.gz  
gnustep-make-2.7.0.tar.gz

and am testing it on Ubuntu 16.04. The sources built without issues. That's good. 

However, I seem to be far away from getting anything from our software stack to run on the current GNUstep sources. I have already fixed an issue with NSTabView (will report/summarize later) but had to go back to zero with the most simple test app to test out gui and back. 

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? I guess this is more a back issue than gui!? If I remember correctly 

tar xvfz gnustep-back-0.25.1.tar.gz
cd gnustep-back-0.25.1
./configure
make
make install
cd ..

chose cairo on the current Ubuntu machine!? I used to have lib-art under Solaris!?





_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Andreas Höschler
In reply to this post by Andreas Höschler
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?

Mit freundlichen Grüßen,

Andreas Höschler
Managing Director

Smartsoft GmbH
Birkenweg 11a
21483 Gülzow
Tel: 040 60889019





_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:
>
> 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?
>


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

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


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

H. Nikolaus Schaller
Hi Andreas,
still alive? (same question goes to me :)

> Am 21.04.2018 um 16:43 schrieb Andreas Höschler <[hidden email]>:
>
> NSWindow::drawRect:display:

does this really exist?

Apple is usually keeping deprecated methods in documentation for a long time:

        https://developer.apple.com/documentation/appkit/nswindow?language=objc

but there are only display methods but no drawRect.

Anyways, what should a window draw? Only NSView and NSCell draw something.
So it draws its contentView because that can be defined in a NIB.

Or this is a private method to draw the window decoration?

-- hns
_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Andreas Höschler
In reply to this post by Fred Kiefer
Hi Fred,

> 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?

The incorrect height is passed to the windows contentView from here:

#0  -[GSVBox setFrame:] (self=0x1ed2ed8, _cmd=0x7fcbe908aa10 <.objc_selector_list+672>, rect=...)
    at GSVBox.m:179
#1  0x00007fcbe8c133e9 in -[NSView resizeWithOldSuperviewSize:] (self=0x1ed2ed8,
    _cmd=<optimized out>, oldSize=...) at NSView.m:2089
#2  0x00007fcbe8c941a3 in -[GSWindowDecorationView setFrame:] (self=0x1ecd128,
    _cmd=<optimized out>, frameRect=...) at GSWindowDecorationView.m:411
#3  0x00007fcbe8c29cb1 in -[NSWindow sendEvent:] (self=0x1ed2a48, _cmd=<optimized out>,
    theEvent=0x1f0c4a8) at NSWindow.m:4153
#4  0x00007fcbe083aa75 in -[XGServer(EventOps) processEvent:] (self=<optimized out>,
    _cmd=<optimized out>, event=<optimized out>) at XGServerEvent.m:912
#5  0x00007fcbe0838f53 in -[XGServer(EventOps) receivedEvent:type:extra:forMode:] (
    self=<optimized out>, _cmd=<optimized out>, data=<optimized out>, type=ET_RDESC, extra=0x0,
    mode=0xd) at XGServerEvent.m:309
#6  0x00007fcbe81d7f1f in -[GSRunLoopCtxt pollUntil:within:] (self=<optimized out>,
    _cmd=<optimized out>, milliseconds=0, contexts=<optimized out>) at GSRunLoopCtxt.m:600
#7  0x00007fcbe8120cca in -[NSRunLoop acceptInputForMode:beforeDate:] (self=<optimized out>,
    _cmd=<optimized out>, mode=<optimized out>, limit_date=<optimized out>) at NSRunLoop.m:1224
#8  0x00007fcbe81211bc in -[NSRunLoop runMode:beforeDate:] (self=0x18faa88, _cmd=<optimized out>,
    mode=0x7fcbe85da0a8 <.objc_str>, date=<optimized out>) at NSRunLoop.m:1304
#9  0x00007fcbe8c3c9fa in -[GSDisplayServer(EventOps) getEventMatchingMask:beforeDate:inMode:dequeue:] (self=<optimized out>, _cmd=<optimized out>, mask=4294967295, limit=<optimized out>,

Does this hit any bells? I will dive into the GNustep code and try to make sense out of this ...

Thanks,

 Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Andreas Höschler
In reply to this post by H. Nikolaus Schaller
Hi Nikolaus,

still alive? (same question goes to me :)

:-) Nice to hear/read from you. It seems we are all still there (somewhere)!

NSWindow::drawRect:display:
does this really exist?

Sorry, that was a typo! :-( I meant

NSWindow::setFrame:display:

Anyways, what should a window draw? Only NSView and NSCell draw something.
So it draws its contentView because that can be defined in a NIB.

Or this is a private method to draw the window decoration?

There actually is a 

NSWindow::drawRect:

method in the GNustep code. No idea when this is called (probably not related to my problem). My problem is rather anywhere here in the the sendEvent: method of NSWindow.m.

            case GSAppKitWindowResized:
              {
                NSRect newFrame;

                newFrame.size.width = [theEvent data1];
                newFrame.size.height = [theEvent data2];
                /* Resize events always move the frame origin. The new origin
                   is stored in the event location field. */
                newFrame.origin = [theEvent locationInWindow];
                 
                /* FIXME: For a user resize we should call windowWillResize:toSize:
                   on the delegate.
                 */
                _frame = newFrame;
                newFrame.origin = NSZeroPoint;
                [_wv setFrame: newFrame];
                [_wv setNeedsDisplay: YES];

                if (_autosaveName != nil)
                  {
                    [self saveFrameUsingName: _autosaveName];
                  }
                 
                [self _processResizeEvent];
                [nc postNotificationName: NSWindowDidResizeNotification
                                  object: self];
                break;
              }

I don't understand yet where this

                newFrame.size.height = [theEvent data2];

comes from, but the height is wrong. And my guess is that the height of the window title bar is not subtracted!?

Best wishes,

 Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Fred Kiefer
In reply to this post by Andreas Höschler
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

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Andreas Höschler
Hi Fred,

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

I typed this command in the shell I use to start the app directly after a reboot of the machine. It said

_GNUSTEP_FRAME_OFFESTS: no such atom on any window

I then started the app for the first time after a reboot and reexecuted the above command. It then said

_GNUSTEP_FRAME_OFFSETS(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

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

That's the exact same command as above? Is this correct?

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.

Unfortunately this had no effect. The app still misbehaves. :-(

Starting the app gives

2018-04-23 15:19:39.762 TabTest[4137:4137] Setting contentView <GSVBox: 0x1eba168>
2018-04-23 15:19:39.763 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; height = 53} - <GSVBox: 0x1eba168>
2018-04-23 15:19:39.770 TabTest[4137:4137] setFrame {x = 140; y = 439; width = 85; height = 217} display 0
2018-04-23 15:19:39.772 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; height = 217} - <GSVBox: 0x1eba168>
2018-04-23 15:19:39.774 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; height = 217} - <GSVBox: 0x1eba168>
2018-04-23 15:19:39.775 TabTest[4137:4137] setFrame {x = 140; y = 439; width = 85; height = 217} display 0
2018-04-23 15:19:39.782 TabTest[4137:4137] setFrame {x = 140; y = 439; width = 85; height = 217} display 0

Grabbing the corner of the window (not yet significantly resized) produces

2018-04-23 15:19:44.815 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; height = 248} - <GSVBox: 0x1eba168>
2018-04-23 15:19:44.815 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; height = 248} - <GSVBox: 0x1eba168>
2018-04-23 15:19:44.863 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; height = 247} - <GSVBox: 0x1eba168>
2018-04-23 15:19:44.863 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; height = 247} - <GSVBox: 0x1eba168>

Thanks,

 Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Fred Kiefer


> Am 23.04.2018 um 15:21 schrieb Andreas Höschler <[hidden email]>:
>
>
>> It is easy to inspect these numbers as GNUstep stores them on the root
>> window as properties.
>>  xprop -root _GNUSTEP_FRAME_OFFSETS
>
> I typed this command in the shell I use to start the app directly after a reboot of the machine. It said
>
> _GNUSTEP_FRAME_OFFESTS: no such atom on any window

This is to be expected, as GNUstep needs to fill these values first.

> I then started the app for the first time after a reboot and reexecuted the above command. It then said
>
> _GNUSTEP_FRAME_OFFSETS(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

That looks bad. Most likely GNUstep couldn’t figure out any of these values which again would explain your problem.


>> 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
>
> That's the exact same command as above? Is this correct

No, I forgot to add „-remove“ in the middle of the command. But the result that you have above are enough for now.
Could you please either restart your computer again or execute this remove command
xprop -root -remove _GNUSTEP_FRAME_OFFSETS

And then start you application with the parameter "—GNU-Debug=Offset“ and mail back the output. Newer versions of GNUstep would have a bit more diagnostic here, but I hope the old version will print something as well.

Fred



_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Andreas Höschler
Hi Fred,

No, I forgot to add „-remove“ in the middle of the command. But the result that you have above are enough for now.
Could you please either restart your computer again or execute this remove command
xprop -root -remove _GNUSTEP_FRAME_OFFSETS

And then start you application with the parameter "—GNU-Debug=Offset“ and mail back the output. Newer versions of GNUstep would have a bit more diagnostic here, but I hope the old version will print something as well.

Starting the app:

2018-04-24 10:36:11.292 TabTest[30979:30979] Setting contentView <GSVBox: 0x28bffa8>
2018-04-24 10:36:11.293 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 85; height = 53} - <GSVBox: 0x28bffa8>
2018-04-24 10:36:11.303 TabTest[30979:30979] setFrame {x = 140; y = 345; width = 85; height = 247} display 0
2018-04-24 10:36:11.306 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 85; height = 247} - <GSVBox: 0x28bffa8>
2018-04-24 10:36:11.309 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 85; height = 247} - <GSVBox: 0x28bffa8>
2018-04-24 10:36:11.310 TabTest[30979:30979] setFrame {x = 140; y = 345; width = 85; height = 247} display 0
2018-04-24 10:36:11.318 TabTest[30979:30979] setFrame {x = 140; y = 345; width = 85; height = 247} display 0
2018-04-24 10:36:11.362 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.367 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.372 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.374 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.377 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.379 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.380 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.380 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.395 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.397 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.397 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.397 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.398 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.399 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.426 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.431 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.433 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:11.472 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS

Grabbing the bottom right corner of the window with the mouse in order to resize:

2018-04-24 10:36:19.155 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.170 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.178 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.186 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.202 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.210 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.226 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.234 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.242 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.258 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.266 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.274 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.282 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.306 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.538 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.706 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.778 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:19.826 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:20.090 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:20.322 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:20.434 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:20.506 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:20.538 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.259 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.260 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.260 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 85; height = 280} - <GSVBox: 0x28bffa8>
2018-04-24 10:36:22.260 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 85; height = 280} - <GSVBox: 0x28bffa8>
2018-04-24 10:36:22.263 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.265 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.266 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.266 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.270 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.272 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.298 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.299 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.299 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 85; height = 281} - <GSVBox: 0x28bffa8>
2018-04-24 10:36:22.300 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 85; height = 281} - <GSVBox: 0x28bffa8>
2018-04-24 10:36:22.301 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.302 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.302 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.303 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.306 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.308 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.363 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.363 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.363 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 85; height = 282} - <GSVBox: 0x28bffa8>
2018-04-24 10:36:22.363 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 85; height = 282} - <GSVBox: 0x28bffa8>
2018-04-24 10:36:22.364 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.365 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.366 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.366 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.368 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.370 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.435 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.435 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.435 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 85; height = 283} - <GSVBox: 0x28bffa8>
2018-04-24 10:36:22.435 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 85; height = 283} - <GSVBox: 0x28bffa8>
2018-04-24 10:36:22.436 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.437 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.437 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.438 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.440 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS
2018-04-24 10:36:22.442 TabTest[30979:30979] Offsets retrieved from _NET_FRAME_EXTENTS

Thanks again for looking into this!!

Best wishes,

 Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Ivan Vučica-2
Just staring at those logs...

(1) Which window manager is this?
(2) What does "xprop _NET_FRAME_EXTENTS" tell you when you click on
the offending window? (I think "xwininfo -wm"'s line "Frame extents"
should also be querying the same property.)

Docs on the EWMH-defined window property:
https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472552416

On Tue, Apr 24, 2018 at 9:38 AM, Andreas Höschler <[hidden email]> wrote:

> Hi Fred,
>
> No, I forgot to add „-remove“ in the middle of the command. But the result
> that you have above are enough for now.
> Could you please either restart your computer again or execute this remove
> command
> xprop -root -remove _GNUSTEP_FRAME_OFFSETS
>
> And then start you application with the parameter "—GNU-Debug=Offset“ and
> mail back the output. Newer versions of GNUstep would have a bit more
> diagnostic here, but I hope the old version will print something as well.
>
>
> Starting the app:
>
> 2018-04-24 10:36:11.292 TabTest[30979:30979] Setting contentView <GSVBox:
> 0x28bffa8>
> 2018-04-24 10:36:11.293 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 53} - <GSVBox: 0x28bffa8>
> 2018-04-24 10:36:11.303 TabTest[30979:30979] setFrame {x = 140; y = 345;
> width = 85; height = 247} display 0
> 2018-04-24 10:36:11.306 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 247} - <GSVBox: 0x28bffa8>
> 2018-04-24 10:36:11.309 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 247} - <GSVBox: 0x28bffa8>
> 2018-04-24 10:36:11.310 TabTest[30979:30979] setFrame {x = 140; y = 345;
> width = 85; height = 247} display 0
> 2018-04-24 10:36:11.318 TabTest[30979:30979] setFrame {x = 140; y = 345;
> width = 85; height = 247} display 0
> 2018-04-24 10:36:11.362 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.367 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.372 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.374 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.377 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.379 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.380 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.380 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.395 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.397 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.397 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.397 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.398 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.399 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.426 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.431 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.433 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.472 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
>
> Grabbing the bottom right corner of the window with the mouse in order to
> resize:
>
> 2018-04-24 10:36:19.155 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.170 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.178 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.186 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.202 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.210 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.226 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.234 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.242 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.258 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.266 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.274 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.282 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.306 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.538 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.706 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.778 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.826 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:20.090 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:20.322 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:20.434 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:20.506 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:20.538 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.259 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.260 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.260 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 280} - <GSVBox: 0x28bffa8>
> 2018-04-24 10:36:22.260 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 280} - <GSVBox: 0x28bffa8>
> 2018-04-24 10:36:22.263 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.265 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.266 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.266 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.270 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.272 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.298 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.299 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.299 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 281} - <GSVBox: 0x28bffa8>
> 2018-04-24 10:36:22.300 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 281} - <GSVBox: 0x28bffa8>
> 2018-04-24 10:36:22.301 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.302 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.302 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.303 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.306 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.308 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.363 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.363 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.363 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 282} - <GSVBox: 0x28bffa8>
> 2018-04-24 10:36:22.363 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 282} - <GSVBox: 0x28bffa8>
> 2018-04-24 10:36:22.364 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.365 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.366 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.366 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.368 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.370 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.435 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.435 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.435 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 283} - <GSVBox: 0x28bffa8>
> 2018-04-24 10:36:22.435 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 283} - <GSVBox: 0x28bffa8>
> 2018-04-24 10:36:22.436 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.437 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.437 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.438 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.440 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:22.442 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
>
> Thanks again for looking into this!!
>
> Best wishes,
>
>  Andreas
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Andreas Höschler
Hi Ivan,

Just staring at those logs...

(1) Which window manager is this?

I actually don't know. This is a preinstalled Ubuntu system. It has a vertical doc on the left side of the screen. How do I figure this out?

(2) What does "xprop _NET_FRAME_EXTENTS" tell you when you click on
the offending window?

It says

_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 32, 0

(I think "xwininfo -wm"'s line "Frame extents"
should also be querying the same property.)

Yes, it returns the same info!

What does that mean for/in my case? 

Thanks,

 Andreas



_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Liam Proven
On 24 April 2018 at 17:20, Andreas Höschler <[hidden email]> wrote:
>
> I actually don't know. This is a preinstalled Ubuntu system. It has a
> vertical doc on the left side of the screen. How do I figure this out?

If you can tell me what exact version of Ubuntu you are running, and
what desktop, I can tell you what the WM is.

E.g. if the version is 16.04 (the current long-term support version),
then the default desktop is Unity and the WM is Compiz.

If it is the latest released version, 17.10, then the default desktop
is GNOME 3 (with Ubuntu customisations) and the window manager is
Clutter, but this is inexact as it is not running X.11 but Wayland and
there is no traditional WM.

If you are running a beta of 18.04, the forthcoming LTS version, then
again, it's GNOME 3 and Clutter under Wayland.

--
Liam Proven • Profile: https://about.me/liamproven
Email: [hidden email] • Google Mail/Hangouts/Plus: [hidden email]
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven
UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Fred Kiefer
In reply to this post by Andreas Höschler
All of these values look correct, I really don’t understand why it is going wrong here. I see two ways to proceed from here. Either you could move on to a more current GNUstep version just to see whether the error is resolved there. Or I could write a tiny test application, check it locally with current GNustep and send you the test code to confirm the behaviour on your side.

I hope to find the time for the later, but am promising nothing for this week.

Fred

> Am 24.04.2018 um 17:20 schrieb Andreas Höschler <[hidden email]>:
>
> Hi Ivan,
>
>> Just staring at those logs...
>>
>> (1) Which window manager is this?
>
> I actually don't know. This is a preinstalled Ubuntu system. It has a vertical doc on the left side of the screen. How do I figure this out?
>
>> (2) What does "xprop _NET_FRAME_EXTENTS" tell you when you click on
>> the offending window?
>
> It says
>
> _NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 32, 0
>
>> (I think "xwininfo -wm"'s line "Frame extents"
>> should also be querying the same property.)
>
> Yes, it returns the same info!
>
> What does that mean for/in my case?
>
> Thanks,
>
>  Andreas
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Andreas Höschler
Hi Fred,

All of these values look correct, I really don’t understand why it is going wrong here. I see two ways to proceed from here. Either you could move on to a more current GNUstep version just to see whether the error is resolved there. Or I could write a tiny test application, check it locally with current GNustep and send you the test code to confirm the behaviour on your side.

I hope to find the time for the later, but am promising nothing for this week.

I assume I would find the more recent version on 


I will try the most recent gui and back ...

I am also looking forward to your little test app!

Thanks a lot,

 Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Andreas Höschler
In reply to this post by Liam Proven
Hi Liam,

I actually don't know. This is a preinstalled Ubuntu system. It has a
vertical doc on the left side of the screen. How do I figure this out?

If you can tell me what exact version of Ubuntu you are running, and
what desktop, I can tell you what the WM is.

E.g. if the version is 16.04 (the current long-term support version),
then the default desktop is Unity and the WM is Compiz.

I run 16.04, so I guess that will be it. Any idea how to be sure (command to test this)?

May be I should try to get WindowMaker to run on this box and see whether this makes a difference!?

If it is the latest released version, 17.10, then the default desktop
is GNOME 3 (with Ubuntu customisations) and the window manager is
Clutter, but this is inexact as it is not running X.11 but Wayland and
there is no traditional WM.

If you are running a beta of 18.04, the forthcoming LTS version, then
again, it's GNOME 3 and Clutter under Wayland.

Woahhj!!

Thanks,

 Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Andreas Höschler

On Apr 24, 2018, at 6:53 PM, Andreas Höschler wrote:

E.g. if the version is 16.04 (the current long-term support version),
then the default desktop is Unity and the WM is Compiz.

I run 16.04, so I guess that will be it. Any idea how to be sure (command to test this)?

May be I should try to get WindowMaker to run on this box and see whether this makes a difference!?

I tried to get Window Maker to run to figure out whether the problem is window manager related. I did
add-apt-repository ppa:profzoom/wmaker
apt-get update
apt-get install wmaker



logged out and tried to login after selecting Window Maker in the login panel. This does not work. I am not logged in but routed back to the login screen! :-(

Any experiences with Window Maker and its installation on an Ubuntu 16.04 system?

Thanks a lot,

 Andreas


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Bugs in gui/back

Andreas Höschler
Hi all,

I tried to install a different window manager on this Ubuntu 16.04 box to check out whether the problem is window manager related. I tried Window Maker 

add-apt-repository ppa:profzoom/wmaker
apt-get update
apt-get install wmaker

and was even able to select that on the login screen. But logging in got me immediately rerouted to the login screen. So it simply did not work. I tried a bunch of other window managers from 


without success. Not one wanted to work. Pretty annoying and discouraging experience so far. The machine is now completely messed up. I not even get back into the original Unity 8 desktop. After a reboot I end up on some kind of xfce login screen with no option to choose a different window manager. :-(

It might be the time for a complete reinstall of the OS. Since the Linux was preinstalled on this machine I do not even have an install CD and would have to create one first. This brings me to the question which distro to use.

What's the quickest and cleanest way to set up a Linux/GNUstep machine on current hardware? Which distro do you recommend? Is there a todo-list somewhere to get from naked hardware to a working GNUstep desktop somewhere?

These kind of problems made me stick to Solaris and MacOSX for so long. Both just worked. This Linux crap gives me a hard time .. :-(

Hints greatly appreciated!!

Thanks,

 Andreas



_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
123