Fix Force 4:3 Aspect Ratio not working if Resizable window is enabled (#6062) #6107
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…6062 AI assisted fix, seems to work fine after a second iteration. Tested in WSL linux -a bit shaky to resize windows in this environment by default, but seems to behave fine now.
Member
|
This doesn't work correctly, at all, it resizes the window to 4:3 instead of resizing the contents, and on the next resize, it's no longer forced to 4:3. |
Not fully sure this is much different from the previous solution, but proof of test working as expected.
Contributor
Author
|
Tried a few more iterations but this time in MinGW Windows. |
Member
|
I'm on Windows 11. But anyway, waiting for the new version to compile so I can test it. |
Contributor
Author
|
Thanks either way for your timely responses and for following up on this. My compromise to own the fix stays -if something goes wrong, I will take the hit to fix or undo anything needed fast. |
Member
|
OK, now it works! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
I finally decided to give this a go myself: … #6062
Summary of the issue is that force aspect 4:3 is ignored when resizing window is enabled.
AI assisted fix. Its explanation (seems reasonable):
The root of the bug is that 86Box’s UI only applies the 4:3 constraint when it handles its own resize requests. In qt_mainwindow.cpp the function MainWindow::resizeEvent(QResizeEvent *event) returns immediately whenever the window is either in fullscreen or the Resizable window mode (vid_resize==1). When this early return is hit the program does not emit a resizeContents signal, so the code that adjusts the stack‑widget size and calls setFixedSize in the constructor’s lambda is skipped. The only place where the 4:3 option force_43 is used in the Qt layer is to tick the menu entry and toggle the flag via video_toggle_option; neither resizeEvent nor the resizeContents handler look at force_43. Consequently, when Resizable window is enabled the user can drag the window to arbitrary aspect ratios, and the forced 4:3 mode is silently ignored.
A practical fix is to enforce the aspect ratio in the UI whenever the user resizes the window while force_43 is active.
Tested in Windows 11 WSL Ubuntu compiling Linux -a bit shaky to resize windows in this environment by default, but seems to behave fine now -it needed a 2nd iteration to get the fix right. Verified checking/unchecking Force 4:3 aspect and Resizing window.
Also verified two machines opened at the same time.
I would recommend additional testing if the fix is accepted as I am not versed in Qt and could only test one mixed config. I can help further re-testing Windows -preferably getting a built executable.
Either way, I am responsible for the fix and would follow up within a day max if something needs to be changed or the fix reverted.
Checklist
References
N/A