Fix Force 4:3 Aspect Ratio not working if Resizable window is enabled (#6062)#6107
Conversation
…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.
|
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.
|
Tried a few more iterations but this time in MinGW Windows. |
|
I'm on Windows 11. But anyway, waiting for the new version to compile so I can test it. |
|
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. |
|
OK, now it works! |
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