Obs-studio: deps: Update Qt to 5.15.2 on Windows and macOS

[RytoEX]

TLDR; Plugin Developers: If your plugin depends on Qt, it will stop working when users update to OBS 26.1.0. You will have to release an update of your plugin built with Qt 5.15.2.

This is a meta/tracking issue to communicate intent to update OBS to Qt 5.15.2 and track any related issues. At this time, the intent is to update to Qt 5.15.2 for OBS 26.1.

Rationale

On Windows, OBS is built with Qt 5.10.1. On macOS, OBS is built with Qt 5.14.1. We should build OBS on Windows and macOS with Qt 5.15.2. This would bring us up to date with a current and currently supported release of Qt and bring Windows and macOS builds closer in terms of dependencies and expected behavior.

[RytoEX]

Pinging a few plugin devs that I know of.

@Palakis @pkviet @exeldro

[RytoEX]

I forgot to add @WarmUpTill above.

[WizardCM]

To further elaborate on why we're updating Qt:

1. This will finally fix how OBS is displayed on High DPI monitors on Windows #2634

2. This will re-enable the displayed keyboard shortcuts in context menus, improving the user experience

3. A lot of Qt versions between 5.10.1 (current) and 5.15.2 introduced new bugs & workarounds that we were not comfortable shipping

4. We generally don't like updating Qt too often because it means certain OBS plugins that depend on it won't function until they update too

---

As a side note, the reason this Issue doesn't mention Linux: each version & distro comes with its own Qt version, and we cannot control which each ships with.

[willlllllio]

Any rough ETA when this will release?

[alinsavix]

This seems like it's enough of a breaking change that it should really be v27 rather than v26.1 ... that's kind of the intended use of the major.minor.micro version number scheme, after all -- big breaking changes get a new major number.

It would be really weird if 24 -> 25 -> 26 upgrades were pretty much 100% backwards compatible ... but then 26 -> 26.1 wasn't...

[dodgepong]

@alinsavix That's a great point. However, I think it's still worth upgrading Qt in a minor version for a number of reasons:

1. We've never really used semantic versioning of OBS versions for API changes. If we had, then 24 -> 25 -> 26 _wouldn't_ have been backwards compatible. Our version numbers have largely been feature-based, i.e. major new versions come with major new features. I realize that can be confusing on the developer side, and there's an argument to be made that we _should_ start properly using semantic versioning, or at least maintain a separate internal version number specifically for the API, but that's a conversation for another time.

2. Because major releases come with major features, upgrading Qt at the same time could muddy the waters in terms of support. If people report issues to us in a major release, it could be unclear whether the cause is an upgrade to Qt, or a bug in the implementation of a feature. By isolating dependency upgrades to an otherwise uninteresting update, we can more clearly track bugs back to a dependency update.

[dodgepong]

I'm very concerned specifically about the StreamDeck plugin. Early indications suggest that it doesn't work with 5.15.2 due to its inclusion of QtNetwork. While Elgato could release a new version of the plugin with an updated QtNetwork, I personally don't feel like that's a good long-term solution, especially because the plugin loses backwards compatibility. The _real_ solution would be for Elgato to stop using QtNetwork for establishing a local socket, but that is likely going to be a longer project, one that Elgato may not be able to finish prior to our expected 26.1 launch timeline.

I'd like to open a dialog with Elgato about this, as many OBS users are avid fans of the StreamDeck, and it's worth our time to make sure those users are handled properly. For what it's worth, we are still planning on releasing 26.2 before the end of the year.

[willlllllio]

@dodgepong Have you considered officially shipping QtNetwork with OBS yourself on Windows too? You already do on MacOS I believe. I've seen a couple of plugins use it by themselves and even considered it myself too but only didn't because of the possible issues on upgrades like now.

Only like 1MB more zipped and would make life for many plugin devs a lot easier. I get it's a bit weird including it as you don't use it yourself but since OBS' UI is Qt basically every plugin will be using it for UI so having easy networking available within it for any plugin dev that wants to use it would be really nice. I think you ship libcurl and there're some http helper API functions but having full qtnetwork which integrates nicely into the Qt event loop would seem way more convenient for plugins sometimes.

[dodgepong]

I think bloat was a small reason for its exclusion on Windows. The bigger reason we didn't ship with QtNetwork to begin with, from what I understand, was because it required us to build and ship with OpenSSL on Windows. However, Qt 5.13 allows the use of Windows's built-in Secure Channel, so if we don't mind adding a whole MB to the download then we could probably ship with it again. This wasn't an issue on Mac because Qt can use MacOS's system OpenSSL libraries. In fact, I think we started shipping QtNetwork on Mac _specifically_ because of the StreamDeck plugin.

I think we could ship QtNetwork on Windows now, but we just have to add some code to intercept StreamDeck's loading of QtNetwork and replace it without own. If that works correctly, then we would have a path forward toward shipping 5.15.2 while maintaining backwards compatibility with the existing StreamDeck plugin.

[elgatosystems]

Hey from Elgato 👋

Thanks a lot for the notification and the great explanations.
We would be interested to get access to an OBS 26.1 beta compiled with Qt 5.15.2. Any idea when it will be available for testing?

If the Stream Deck plugin is not compatible with OBS 26.1, we could plan an update along OBS 26.1. Let us know once there are further details.

[dodgepong]

There should be a test build available pretty soon. With this commit the StreamDeck plugin should work correctly, but please do test it yourself once the test build is live.