Broken main tabs and small font size 6-21 Windows nightly

[rwbaer]

The current Windows nightly 1.2.0 beta2 has dysfunctional major tabs and very very small font size on all tabs.

Dysfunctional tabs means: 1) clicking on them doesn't do anything; and 2) there are two community tabs showing on the interface.

[joepal1976]

And this works on the same machine with beta 1?

I'll lean towards suspecting that https://github.com/makehumancommunity/makehuman/pull/98 had unforeseen side-effects.

[joepal1976]

@dennj : I'm going to comment out the high-resolution changes for a while to see if this solves the problem.

[joepal1976]

This will arrive in tomorrow's build. If this makes things work as expected on your machine, I'll proceed to try to make the highres changes optional.

[Aranuvir]

If Rob's issue was solved by Joel's actions in the code, I'd suggest to control the behavior via an option in the settings tab.

[rwbaer]

Windows 10 nightly - 1.2.0 beta2 (HEAD:226d6488) (nightly 6-24) All tabs seem to be working fine right now with this nightly. Didn't get around to testing yesterday's nightly because Tuxfamily was downloading too slowly.

Because of the nature of this issue, it is useful that I provide more information about the computer I encountered the problem on. It is a dual monitor desktop machine. One monitor has a resolution of 3840 x 2160. The second monitor has a resolution of 1920 x 1080. Both monitors are driven by an old Nvidia Quadro K2000 graphics card. The first monitor has a scale and layout setting of 150%. The second monitor has a scale and layout setting of 100%. Perhaps @dennj was not picturing such a configuration.

[Aranuvir]

OK. I'll add an option in the settings the next days. Any other opinion?

[dennj]

I guess there are more people using a single HD monitor than a configuration double monitor: HD and low resolution together. So I would suggest to keep the HD monitor support on, but leave an option to disable it.

[Aranuvir]

I think HDPI is still less common. So there is an opt in rather than an opt out on the _feature_hdpi_option branch. Testers are welcome. I cannot fully verify the code correctness...

[rwbaer]

MH 1.2.0 beta2 (_feature_hdpi_option:733208f2) Windows OS Build 19041.330 A bit of real life ... I tested your source and the behavior is gone whether you new HDPI setting is checked or not. Hmmm... What;s going on? Don't know but here are some ideas/info.

Dependencies: When testing the feature source PyQt5 5.15.0 (pypi) pyqt5-sip 12.8.0 (pypi) numpy 1.18.5 pyopengl 3.1.1a1

I am pretty sure I did a Windows update since the last test, but I can't be positive. The latter might be tested by trying the windows installer version (1.2.0 beta2 (HEAD:226d6488)). This now seems to be working correctly. Conclusion - perhaps this was a Windows issue and not an MH issue.

NOTATION: With the dependencies listed above, I had a recurrence of the slider issues where pulling down on a slider collapses the grouping boxes in settings. I can not remember what PyQt I should not be using. Was it 15.5.0? The Windows build version does not have this problem.

[rwbaer]

Question. Does the Windows build version include the HDPI?. I am thinking yes as I write the above.

Also, during startup with the dependencies listed above the splash screen goes black for a time and then comes back on. This does not happen on the build version. Then just as the human appears for the first time, the viewport is entirely white for a fraction of a second. This goes away and does not seem to be an issue, but it reminds me of the openGL problems we had for a while. The splash screen blanking with the feature branch seems entirely new. Does it happen in Linux?

[joepal1976]

PyQT is only supported up to 5.12. Higher than that and the UI will be broken.

@rwbaer : Since the HDPI option is now configurable in settings -> general, can we close this?

[Aranuvir]

Guess it's fixed, though I do not have enough pixels to test ...