| Summary: | Window reports wrong position after size restored from maximized on X11 | ||
|---|---|---|---|
| Product: | [JogAmp] Newt | Reporter: | Colin DuPée <Pragmataraxia> |
| Component: | x11 | Assignee: | Sven Gothel <sgothel> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | --- | ||
| Version: | 2.3.2 | ||
| Hardware: | pc_x86_64 | ||
| OS: | linux | ||
| Type: | --- | SCM Refs: | |
| Workaround: | --- | ||
| Attachments: | Simple windows spits out bounds info to stdout on move/resize/click. | ||
(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(..). > 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. (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> (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. |
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. 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.