1221 2015-09-18 15:52:23 +0200 Window reports wrong position after size restored from maximized on X11 2015-09-27 01:23:54 +0200 1 1 3 JogAmp Newt x11 2.3.2 pc_x86_64 linux RESOLVED WORKSFORME --- normal --- 0 Pragmataraxia sgothel --- --- oldest_to_newest 5153 0 737 Pragmataraxia 2015-09-18 15:52:23 +0200 Created attachment 737 Simple windows spits out bounds info to stdout on move/resize/click. This is really several bugs, but they're likely related. For all of the above, simply have a GLWindow visible. 1) Reported position after maximize/restore - Move window to non-default position. - Double-click title bar to maximize. - Double-click title bar to restore. Result: Window returns to original position, but getX()/getY() report another position. If you register a WindowListener, you can see that 3 events appear upon restore, the middle of which is the correct position, but the first and last are wrong. 2) WindowListener's windowResize() receives no updates until mouse released. Expected: new event arrives when window changes size. Observed: no events appear until mouse is released, then entire queue of updates are delivered. Neither of these problems appear on Windows. As a bonus bug for all platforms... 3) Iterative getting/setting position results in windows moving upward. I have no details on this one yet, so I can't really file it yet, but I have a number of windows where I try to save their positions, and restore them when the application is re-launched. Sometimes, the restored windows have moved upward about the thickness of the window decorations. It happens infrequently enough that I'm not even sure if the problem is in get or set, but it's driving me bonkers. 5186 1 sgothel 2015-09-22 05:11:28 +0200 (In reply to Colin DuPée from comment #0) > Created attachment 737 [details] > Simple windows spits out bounds info to stdout on move/resize/click. > > This is really several bugs, but they're likely related. For all of the > above, simply have a GLWindow visible. > > 1) Reported position after maximize/restore > - Move window to non-default position. > - Double-click title bar to maximize. > - Double-click title bar to restore. > > Result: Window returns to original position, but getX()/getY() report > another position. > > If you register a WindowListener, you can see that 3 events appear upon > restore, the middle of which is the correct position, but the first and last > are wrong. I will look into this. This reported issue seems to be valid. > > 2) WindowListener's windowResize() receives no updates until mouse released. > Expected: new event arrives when window changes size. > Observed: no events appear until mouse is released, then entire queue of > updates are delivered. > > Neither of these problems appear on Windows. This depends on the native window manager, not NEWT. We deliver all resize events on X11, OSX, .. > > As a bonus bug for all platforms... > > 3) Iterative getting/setting position results in windows moving upward. > I have no details on this one yet, so I can't really file it yet, but I > have a number of windows where I try to save their positions, and restore > them when the application is re-launched. Sometimes, the restored windows > have moved upward about the thickness of the window decorations. It happens > infrequently enough that I'm not even sure if the problem is in get or set, > but it's driving me bonkers. "Iterative getting/setting position" I assume you mean programmatically setting the position here. Please check the API doc of NEWT, e.g.: Window.setPosition(..): 'Sets the location of the window's client area excluding insets (window decorations) in window units.' <http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/newt/Window.html#setPosition%28int,%20int%29> Hence you would need to take the window decoration into account, see the convenient methods: Window.setTopLevelPosition(..) <http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/newt/Window.html#setTopLevelPosition%28int,%20int%29> .. there is also an: Window.setTopLevelSize(..). 5188 2 Pragmataraxia 2015-09-22 06:18:38 +0200 > This depends on the native window manager, not NEWT. > We deliver all resize events on X11, OSX, .. I wondered if that might be the case. This particular machine is using LXDE, in case that's ever relevant to anyone. > Hence you would need to take the window decoration into account The setTopLevel*() methods are useful, but are there related getTopLevel*() methods to go with them? Just to clarify, the problem isn't that the windows move up with each setPosition(), the incorrect behavior happens only rarely; which is much worse. The only reason I haven't filed it as a real report yet is that because it's rare, I don't know if the problem is with setPosition() or getBounds(). I've promised the guys in the lab a doughnut if they can find a way to reproduce this problem. 5189 3 sgothel 2015-09-22 06:29:57 +0200 (In reply to Colin DuPée from comment #2) > > This depends on the native window manager, not NEWT. > > We deliver all resize events on X11, OSX, .. > > I wondered if that might be the case. This particular machine is using > LXDE, in case that's ever relevant to anyone. > > > Hence you would need to take the window decoration into account > > The setTopLevel*() methods are useful, but are there related getTopLevel*() > methods to go with them? Nope :) Since .. well, we can think about it. However, adding two new methods in favor of adding the insets is a bit too lazy :) > > Just to clarify, the problem isn't that the windows move up with each > setPosition(), the incorrect behavior happens only rarely; which is much > worse. The only reason I haven't filed it as a real report yet is that > because it's rare, I don't know if the problem is with setPosition() or > getBounds(). I've promised the guys in the lab a doughnut if they can find > a way to reproduce this problem. I never liked this kind of bakery :) Don't forget that on X11, we can only _request_ a window position, where the WM is not required to fulfill our wishes. This may reflect the rare reproduction of the issue. On a side note, always consider contracting us if appropriate :) <https://jogamp.org/wiki/index.php/Maintainer_and_Contacts#Sven_Gothel> 5248 4 sgothel 2015-09-26 06:44:54 +0200 (In reply to Sven Gothel from comment #1) > (In reply to Colin DuPée from comment #0) > > Created attachment 737 [details] > > Simple windows spits out bounds info to stdout on move/resize/click. > > > > This is really several bugs, but they're likely related. For all of the > > above, simply have a GLWindow visible. > > > > 1) Reported position after maximize/restore > > - Move window to non-default position. > > - Double-click title bar to maximize. > > - Double-click title bar to restore. > > > > Result: Window returns to original position, but getX()/getY() report > > another position. > > > > If you register a WindowListener, you can see that 3 events appear upon > > restore, the middle of which is the correct position, but the first and last > > are wrong. > > I will look into this. > This reported issue seems to be valid. > Tested on GNU/Linux x86_64, Debian 8, KDE WM, NV driver using com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT. (The latter shows bounds in title bar and prints it) Cannot confirm, either via mouse-click maximize, nor programmatic pressing 'm'. Tested w/ latest tip of master branch. Closing .. pls reopen if you can reproduce it, in such case you would need to give more details. WM: KDE and/or Gnome. If it fails w/ others .. we shall ignore it. 737 2015-09-18 15:52:23 +0200 2015-09-18 15:52:23 +0200 Simple windows spits out bounds info to stdout on move/resize/click. TestNewt.java text/plain 3280 Pragmataraxia cGFja2FnZSBjb20udGRtZC50ZXN0OwoKaW1wb3J0IGNvbS5qb2dhbXAubmF0aXZld2luZG93LnV0 aWwuUmVjdGFuZ2xlOwppbXBvcnQgY29tLmpvZ2FtcC5uZXd0LkRpc3BsYXk7CmltcG9ydCBjb20u am9nYW1wLm5ld3QuTmV3dEZhY3Rvcnk7CmltcG9ydCBjb20uam9nYW1wLm5ld3QuU2NyZWVuOwpp bXBvcnQgY29tLmpvZ2FtcC5uZXd0LldpbmRvdzsKaW1wb3J0IGNvbS5qb2dhbXAubmV3dC5ldmVu dC5Nb3VzZUV2ZW50OwppbXBvcnQgY29tLmpvZ2FtcC5uZXd0LmV2ZW50Lk1vdXNlTGlzdGVuZXI7 CmltcG9ydCBjb20uam9nYW1wLm5ld3QuZXZlbnQuV2luZG93RXZlbnQ7CmltcG9ydCBjb20uam9n YW1wLm5ld3QuZXZlbnQuV2luZG93TGlzdGVuZXI7CmltcG9ydCBjb20uam9nYW1wLm5ld3QuZXZl bnQuV2luZG93VXBkYXRlRXZlbnQ7CmltcG9ydCBjb20uam9nYW1wLm5ld3Qub3BlbmdsLkdMV2lu ZG93OwppbXBvcnQgY29tLmpvZ2FtcC5vcGVuZ2wuR0wyOwppbXBvcnQgY29tLmpvZ2FtcC5vcGVu Z2wuR0xBdXRvRHJhd2FibGU7CmltcG9ydCBjb20uam9nYW1wLm9wZW5nbC5HTENhcGFiaWxpdGll czsKaW1wb3J0IGNvbS5qb2dhbXAub3BlbmdsLkdMRXZlbnRMaXN0ZW5lcjsKaW1wb3J0IGNvbS5q b2dhbXAub3BlbmdsLkdMUHJvZmlsZTsKCnB1YmxpYyBjbGFzcyBUZXN0TmV3dCBpbXBsZW1lbnRz IFdpbmRvd0xpc3RlbmVyLCBHTEV2ZW50TGlzdGVuZXIsIE1vdXNlTGlzdGVuZXIKewoJcHVibGlj IHN0YXRpYyB2b2lkIG1haW4oU3RyaW5nW10gYXJncykKCXsKCQluZXcgVGVzdE5ld3QoKTsKCX0K CQoJcHVibGljIFRlc3ROZXd0KCkKCXsKCQlHTFByb2ZpbGUgZ2xwID0gR0xQcm9maWxlLmdldChH TFByb2ZpbGUuR0wyKTsKCQlHTENhcGFiaWxpdGllcyBjYXBzID0gbmV3IEdMQ2FwYWJpbGl0aWVz KGdscCk7CgkJRGlzcGxheSBkcHkgPSBOZXd0RmFjdG9yeS5jcmVhdGVEaXNwbGF5KG51bGwpOwoJ CVNjcmVlbiBzY3JlZW4gPSBOZXd0RmFjdG9yeS5jcmVhdGVTY3JlZW4oZHB5LCAwKTsKCQlHTFdp bmRvdyB3aW4gPSBHTFdpbmRvdy5jcmVhdGUoc2NyZWVuLCBjYXBzKTsKCQl3aW4uc2V0VGl0bGUo IlRlc3QgTWUiKTsKCQl3aW4uc2V0UG9zaXRpb24oMTAwLCAxMDApOwoJCXdpbi5zZXRTaXplKDMw MCwgMzAwKTsKCQl3aW4uYWRkV2luZG93TGlzdGVuZXIodGhpcyk7CgkJd2luLmFkZEdMRXZlbnRM aXN0ZW5lcih0aGlzKTsKCQl3aW4uYWRkTW91c2VMaXN0ZW5lcih0aGlzKTsKCQl3aW4uc2V0Vmlz aWJsZSh0cnVlKTsKCQkKCQl3aGlsZSAod2luLmlzVmlzaWJsZSgpKQoJCXsKCQkJdHJ5CgkJCXsK CQkJCVRocmVhZC5zbGVlcCg1MDApOwoJCQl9CgkJCWNhdGNoIChJbnRlcnJ1cHRlZEV4Y2VwdGlv biBlKXt9CgkJfQoJfQoKCUBPdmVycmlkZQoJcHVibGljIHZvaWQgd2luZG93UmVzaXplZChXaW5k b3dFdmVudCBlKQoJewoJCWlmICghV2luZG93LmNsYXNzLmlzSW5zdGFuY2UoZS5nZXRTb3VyY2Uo KSkpCgkJCXJldHVybjsKCQkKCQlSZWN0YW5nbGUgcmVjdCA9ICgoY29tLmpvZ2FtcC5uZXd0Lldp bmRvdyllLmdldFNvdXJjZSgpKS5nZXRCb3VuZHMoKTsKCQlTeXN0ZW0ub3V0LnByaW50bG4oU3Ry aW5nLmZvcm1hdCgiUmVzaXplZDogKCVkICVkKSwgJWQgeCAlZCIsIHJlY3QuZ2V0WCgpLCByZWN0 LmdldFkoKSwgcmVjdC5nZXRXaWR0aCgpLCByZWN0LmdldEhlaWdodCgpKSk7Cgl9CgoJQE92ZXJy aWRlCglwdWJsaWMgdm9pZCB3aW5kb3dNb3ZlZChXaW5kb3dFdmVudCBlKQoJewoJCWlmICghV2lu ZG93LmNsYXNzLmlzSW5zdGFuY2UoZS5nZXRTb3VyY2UoKSkpCgkJCXJldHVybjsKCQkKCQlSZWN0 YW5nbGUgcmVjdCA9ICgoY29tLmpvZ2FtcC5uZXd0LldpbmRvdyllLmdldFNvdXJjZSgpKS5nZXRC b3VuZHMoKTsKCQlTeXN0ZW0ub3V0LnByaW50bG4oU3RyaW5nLmZvcm1hdCgiTW92ZWQ6ICglZCAl ZCksICVkIHggJWQiLCByZWN0LmdldFgoKSwgcmVjdC5nZXRZKCksIHJlY3QuZ2V0V2lkdGgoKSwg cmVjdC5nZXRIZWlnaHQoKSkpOwoJfQoKCUBPdmVycmlkZQoJcHVibGljIHZvaWQgd2luZG93RGVz dHJveU5vdGlmeShXaW5kb3dFdmVudCBlKXt9CglwdWJsaWMgdm9pZCB3aW5kb3dEZXN0cm95ZWQo V2luZG93RXZlbnQgZSl7fQoJcHVibGljIHZvaWQgd2luZG93R2FpbmVkRm9jdXMoV2luZG93RXZl bnQgZSl7fQoJcHVibGljIHZvaWQgd2luZG93TG9zdEZvY3VzKFdpbmRvd0V2ZW50IGUpe30KCXB1 YmxpYyB2b2lkIHdpbmRvd1JlcGFpbnQoV2luZG93VXBkYXRlRXZlbnQgZSl7fQoKCUBPdmVycmlk ZQoJcHVibGljIHZvaWQgaW5pdChHTEF1dG9EcmF3YWJsZSBkcmF3YWJsZSkKCXsKCQlHTDIgZ2wg PSBkcmF3YWJsZS5nZXRHTCgpLmdldEdMMigpOwoJCWdsLmdsQ2xlYXJDb2xvcigwLjBmLCAwLjBm LCAwLjBmLCAwLjBmKTsKCX0KCglAT3ZlcnJpZGUKCXB1YmxpYyB2b2lkIGRpc3BsYXkoR0xBdXRv RHJhd2FibGUgZHJhd2FibGUpCgl7CgkJR0wyIGdsID0gZHJhd2FibGUuZ2V0R0woKS5nZXRHTDIo KTsKCQlnbC5nbENsZWFyKEdMMi5HTF9DT0xPUl9CVUZGRVJfQklUIHwgR0wyLkdMX0RFUFRIX0JV RkZFUl9CSVQpOwoJfQoKCXB1YmxpYyB2b2lkIGRpc3Bvc2UoR0xBdXRvRHJhd2FibGUgZHJhd2Fi bGUpe30KCXB1YmxpYyB2b2lkIHJlc2hhcGUoR0xBdXRvRHJhd2FibGUgZHJhd2FibGUsIGludCB4 LCBpbnQgeSwgaW50IHdpZHRoLCBpbnQgaGVpZ2h0KXt9CgoJQE92ZXJyaWRlCglwdWJsaWMgdm9p ZCBtb3VzZUNsaWNrZWQoTW91c2VFdmVudCBlKQoJewoJCVJlY3RhbmdsZSByZWN0ID0gKChjb20u am9nYW1wLm5ld3QuV2luZG93KWUuZ2V0U291cmNlKCkpLmdldEJvdW5kcygpOwoJCVN5c3RlbS5v dXQucHJpbnRsbihTdHJpbmcuZm9ybWF0KCJDbGlja2VkOiAoJWQgJWQpLCAlZCB4ICVkIiwgcmVj dC5nZXRYKCksIHJlY3QuZ2V0WSgpLCByZWN0LmdldFdpZHRoKCksIHJlY3QuZ2V0SGVpZ2h0KCkp KTsKCX0KCglAT3ZlcnJpZGUKCXB1YmxpYyB2b2lkIG1vdXNlRW50ZXJlZChNb3VzZUV2ZW50IGUp e30KCXB1YmxpYyB2b2lkIG1vdXNlRXhpdGVkKE1vdXNlRXZlbnQgZSl7fQoJcHVibGljIHZvaWQg bW91c2VQcmVzc2VkKE1vdXNlRXZlbnQgZSl7fQoJcHVibGljIHZvaWQgbW91c2VSZWxlYXNlZChN b3VzZUV2ZW50IGUpe30KCXB1YmxpYyB2b2lkIG1vdXNlTW92ZWQoTW91c2VFdmVudCBlKXt9Cglw dWJsaWMgdm9pZCBtb3VzZURyYWdnZWQoTW91c2VFdmVudCBlKXt9CglwdWJsaWMgdm9pZCBtb3Vz ZVdoZWVsTW92ZWQoTW91c2VFdmVudCBlKXt9Cgp9Cg==