Resize fix for Gnome - #705
Conversation
This reverts commit 3512c86.
|
I tried to download this PR's build but see it has not released anything. What happened? |
This is from the way you set up originally: My PR comes from my fork (as do all my PRs). Maybe this rule is something that should be changed (but not in this PR)? You can find builds here: https://github.com/OoliteProject/oolite/actions/runs/30683865076?pr=705 |
|
Ah yes, that was even intentional to not directly offer stuff noone has tested. For the content: The window resizes smoothly and controllably. But I assumed we wanted base on |
|
@phkb Please let me know if you see any issues |
|
A couple of things. These compile-time messages were new: Fix seems easy enough. Just commenting out these lines in MyOpenGLView.h But given what I find below, I wonder if some of the fixes might be in those functions. A more important issue was, when I ran the build with a saved version of oolite.plist, the opening screen looked like this: That's the complete window. No header, no title bar, no menu. Just a spinning Cobra. The menu is there, however, because I can press the up arrow and enter to exit the game. Pressing F12 a few times gets things back to normal. So that led me to find out what the cause was, and it appears to be the oolite.plist file, and in particular, the "fullscreen" setting. My saved oolite.plist file has Further, if I have the game in full screen mode, and then exit, on next restart I'm back to the black box + Cobra view. So something is going wrong with full screen setting. The only way to have the game start without that view is to not be in full screen mode when exiting. To complicate this further, the screen size settings are not being remembered for non-full-screen settings. No matter how big or small I make the window before I exit, when I restart the game resets to the default size. It looks like the "window_height" and "window_width" settings are being saved in oolite.plist, but they aren't being read on startup. |
phkb
left a comment
There was a problem hiding this comment.
See comments above for summary of issues found.
@phkb hmm ok this might require me to look at the bigger Windows refactoring first. What I have noticed is that the direct Windows calls currently peppered throughout OpenGLView.m result in SDL3's own saved window state being incorrect as they do not update that state. I expect that it still somehow worked before because something was being called for every frame that isn't now. If you have time, can you confirm master behaves correctly and also try https://github.com/mcarans/oolite/releases/tag/1.93.1-resize-fix-from9.1? If not, I'll look at it this weekend (I'm not logged into Windows during the week). EDIT: I spotted an error which I've now fixed: 2c6b5ee. I doubt this will fix the problem though as I think it will only affect resizing on Windows. |
|
First: Master doesn't have this issue. the fullscreen option works as expected, and when in non-fullscreen mode, the window size is saved and correctly restored on restart. I tried both the resize fix 9.1 and the latest code change on this PR and both have the same issues as noted above. |
Glad to hear that it isn't broken in master. Gives me a clear reference to work from. Thanks for testing changes. I think I'll simplify Windows first, then apply Linux changes. Setting this PR to draft. |

Fixes resizing on Gnome @oocube this is resize fix 11.
Improves it for non compositing window manager but may need extra things done on each frame
Some changes do touch code in Windows paths (but didn't cause any issues in my testing)