Emulator Issues #11379
closed[Qt] Controller Settings window fails to load after moving the main window to a different screen.
0%
Description
What's the problem? Describe what went wrong.
If you open the Controller Settings window on one monitor. Close it. And then move the main window to another monitor and reopen the Controller settings it will fail to load.
What steps will reproduce the problem?
1.Open Dolphin
2.Open the controller settings
3.Close the controller settings by clicking on the 'X' in the upper right corner. (If you close it with the "Close" Button on the bottom or with ESC this will not work)
4.Move the Main Window to another screen
5.Reopen the controller settings
Result:
![](Broken Controller Settings.png)
Is the issue present in the latest development version?
Yes. Current Version is 5.0-8715
Which is the first broken version?
What are your PC specifications? (CPU, GPU, Operating System, more)
Windows 10
Files
Updated by JMC4789 over 6 years ago
Do you have a two monitors of different sizes? Qt seems to have problems with DPi changes.
Updated by master0fdisaster1 over 6 years ago
They're the same model. Both 1920x1080
Updated by JMC4789 over 6 years ago
- Assignee set to spycrab0
Neat, probably a bug that hopefully someone else with a standard multi-monitor can reproduce.
Updated by amaiorano about 6 years ago
I was able to repro this problem. I have the exact same setup - 2 1920x1080s. As described, opening the settings dialog on one screen, closing it with the "X", moving Dolphin window to other screen, then opening settings dialog renders all white. Now, if you take this white dialog and move it to the other screen, the controls appear! If you resize the white dialog, the controls appear.
I did some investigating in the code, and my conclusion is this is a Qt bug. I compared the Settings dialog to the Controls one, since this problem doesn't happen with Controls. I stripped down Controls so that it has nothing but the Close button on it, and then it happened with Controls as well. If I add an empty tab page widget, then the problem goes away -- this is true for the Settings dialog as well. If you add a dummy empty tag page widget to it, the problem disappears. So basically, it looks like Qt is refusing to paint the dialog when it opens on a separate screen when certain widgets are not present. Keep in mind that Dolphin creates these dialogs and hides them on start, then simply shows/hides them when opening/closing them, rather than re-creating them. I think this isn't a typical use-case; however, Qt should handle it.
That's as far as I've gone. I have very little Qt experience, so I'm not sure how to proceed. Perhaps a more experienced Qt programmer can actually debug this deeper in Qt to understand it?
Updated by amaiorano about 6 years ago
I'm sorry, I mixed up Controls and Settings dialog in my previous comment. Swap those two in your mind as you read the above!
Updated by spycrab0 almost 5 years ago
- Status changed from New to Questionable
This doesn't seem to happen anymore on the latest master build (we recently upgraded to Qt 5.14.1, that could've possibly fixed it). Please retry using the latest master.
Updated by MayImilae almost 5 years ago
- Operating system Windows added
- Operating system deleted (
N/A)
masterofdisaster, please list your full system specs. You may not think it is necessary, but it is, as it may provide a clue as to what is happening so we can reproduce it.
Updated by master0fdisaster1 almost 5 years ago
Well I just switched out my mainboard literally last friday. So I can't say anything about the bug on my old setup with the current dev version.
My old mainboard is GA-B85M-D2V Don't know what revision with an dual core i3-4360 CPU @ 3.7GHz, 8 GB of DDR3 RAM and a GTX 1060.
My current specs are an Asus Prime Z370-A mainboard with an i3 8350K 4x @ 4.00GHz, 16 GB of DDR4 RAM and a GTX 1060.
I have 2 BenQ GL2450 1920x1080 Monitors, one connected via HDMI and the other via DVI and use Windows 10 Education.
Updated by master0fdisaster1 almost 5 years ago
Well I just tested 5.0-11653 and 5.0-11655 (with 11655 being the QT update).
The bug did happen on 5.0-11653 and didn't happen on 5.0-11655.
Updated by JosJuice almost 5 years ago
- Status changed from Questionable to Fixed
- Fixed in set to 5.0-11655
Marking as fixed, then.