Fixed windowing/windowExample#8210
Conversation
Window position (posx, posy) is now global, rather than being initialized inside ofApp::update (which led to a bug)
Window position (posx, posy) is now global, rather than being initialized inside ofApp::update (which led to a bug)
| ballPositionY += ballVelocityY; | ||
|
|
||
| int posx = ofGetWindowPositionX(); | ||
| int posy = ofGetWindowPositionY(); |
There was a problem hiding this comment.
does this point to a bug/regression with ofGetWindowPositionX / ofGetWindowPositionY ?
This code used to work.
I appreciate the bug fix for the example, but I think the bigger fix might be to understand why ofGetWindowPosition is not working anymore.
There was a problem hiding this comment.
Hi, thanks for the consideration!
If the code used to work, I agree! I can definitely dive into ofGetWindowPosition in order to understand the issue at a deeper level.
Is it ok to share the insights on this matter in this conversation? If you prefer, we close the PR and we open a new one when I find something interesting.
There was a problem hiding this comment.
In fact, the following code is already an issue. Even if it looks like the window is beeing set at exactly the same position it already has, in reality the window keeps moving. Precisely, each time it's set at +6 units in x and +27 units in y, with respect to the current position.
void ofApp::update(){
int posx = ofGetWindowPositionX();
int posy = ofGetWindowPositionY();
ofSetWindowPosition(posx, posy);
}
There was a problem hiding this comment.
which platform are you in? it seems the dimensions of window decoration, status bar and border
There was a problem hiding this comment.
I'm working inside WSL -Windows Subsystem for Linux- with Windows 11 and Debian.
There was a problem hiding this comment.
Update: I found out the thing.
With reference to the figure above:
ofSetWindowPosition sets the position of the red corner (point A).
ofGetWindowPositionX/Y gets the position of the blue corner (point B).
Therefore, the code I showed above retrieves the position of the internal frame and sets the external frame to that position. The net effect is that the window translates by (+6, +27)* each time.
*I verified that (6, 27) is the position of point B with respect to point A.
I don't know if that's the intended behaviour of the functions, or if it arises due to the fact I'm working on WSL.
There was a problem hiding this comment.
which platform are you in? it seems the dimensions of window decoration, status bar and border
Wow, you said it 2 weeks ago. Ops 😆
Sorry, I just realized. Yes, it seems that's definitely the point.
There was a problem hiding this comment.
FWIW the example works correctly on Arch Linux with xorg + i3 (floating window with 10px border).
are you using Wayland? (echo $WAYLAND_DISPLAY)
There was a problem hiding this comment.
I also don't see this issue on macOS or Linux Mint - so it might be a Windows for Linux issue with GLFW?
Can you try the latest nightly and see if it might be fixed in our nightly builds?
https://github.com/openframeworks/openFrameworks/releases/tag/nightly
Thanks!
4 participants
The behaviour was not the expected one.
The bounce of the ball on any of the 4 walls always led to an update of the window position towards positive y, making the window to steadily move towards the lower end of the screen.
This was due to the initialization of the variables describing the window position inside ofApp::update().
Now, the variables are initialized in ofApp.h and they're just updated into ofApp::update().
The behaviour is now as expected.