frontend: Enable Qt strict mode #12567

gxalpha · 2025-08-31T12:05:41Z

Description

Enables Qt strict mode, and makes the changes needed in the codebase to do so.
Strict mode disables "a number of Qt APIs that are deemed suboptimal or dangerous" and that, while not yet officially deprecated, will be removed in the long term. This includes (but isn't limited to) the foreach macro, contextless connects (connect() calls without a receiver), implicit conversions from QByteArray to const char *, and implicit conversions from QString to QUrl.

Motivation and Context

We have previously done cleanups on foreach (see #9662), and things like the contextless connect calls sometimes come up during PR reviews. As can be seen by the first commit, especially the implicit QByteArray->const char * conversions can cause unneeded back-and-forth conversions in some scenarios, not having them is actually advantageous as it reveals the conversions that are happening.
Qt is also moving towards using strict mode themselves (see QTBUG-132327).
By fixing all of these occurrences and turning on strict mode, we prevent the dangerous APIs from being used again in the future.

How Has This Been Tested?

macOS 26.
The code compiles.
I tested in all cases that the connections are still hit, and that conversions still yield the correct results (yes, this took a while.)

Types of changes

Code cleanup (non-breaking change which makes code smaller or more readable)

Checklist:

My code has been run through clang-format.
I have read the contributing document.
My code is not on the master branch.
The code has been tested.
All commit messages are properly formatted and commits squashed where appropriate.
I have included updates to all appropriate documentation.

SetComboByName, SetComboByValue and SetInvalidValue all pass their parameters to Qt functions which only take QStrings. As a consequence, we have cases we'd convert a QString to a const char* to call these functions, only for the functions to implicitly convert them back into QStrings. We can avoid this by passing QStrings directly. In cases where we did actually pass const chars, the (implicit) conversion now just takes place earlier.

tytan652 · 2025-08-31T12:11:50Z

If calling connect() as an object method is meaningless since you add the object in the parameter, wouldn't it be better to replace every call with the closest static definition (e.g. QObject::connect()) ?

gxalpha · 2025-08-31T15:58:15Z

If calling connect() as an object method is meaningless since you add the object in the parameter, wouldn't it be better to replace every call with the closest static definition (e.g. QObject::connect()) ?

I'm not sure what you mean, all connect calls are already using the static declarations (both before and after this PR). Prepending QObject:: wouldn't change anything, except make the code more verbose.
The only non-static connect function that exists in Qt is inline QMetaObject::Connection connect(const QObject *sender, const char *signal, const char *member, Qt::ConnectionType type = Qt::AutoConnection) const; which we're not using as it would need the SIGNAL/SLOT macros.

tytan652 · 2025-08-31T16:07:53Z

Things like object->connect( are completely meaningless with your changes, you can just replace them with connect( or QObject::connect( when outside of a QObject.

gxalpha · 2025-08-31T16:17:47Z

Ah, that's what you mean. I'd argue technically that's not exactly in scope for this change but there's only one instance of that that doesn't use the contextless connect, so I guess I'll add it to this PR.

Qt strict mode disables APIs deemed "'suboptimal' or 'dangerous'" [1] and "clearly undesirable" [2] by Qt that will be removed in the long term. Usages of the APIs in OBS have been removed in the previous commits, and by setting this flag we keep ourselves from using them again. The versioning works in a way where e.g. a new addition to this in 6.9 would only be disabled if at least 0x060900 is set. By setting 0xFF0000, we're effectively disabling any APIs that are deemed to be bad in any future Qt version (up to 255). While this could lead to OBS not being buildable against bleeding edge Qt, it also means that it will be noticed early. Should the disabled API turn out to be too complex to remove, the value can be downgraded to the last working one then. [1] qt/qtbase@3a6c8e0 [2] qt/qtbase@f9163ae

Penwy · 2025-08-31T21:38:49Z

Tested on Ubuntu 24.04, compiles without issues, played around with every different bit of UI I could think of, found no issues.
I am available for any further specific testing if needed.

RytoEX · 2025-09-02T18:45:43Z

Will probably target this for 32.1.

PatTheMav

Looks good overall, I'd prefer if we could replace use of QT_TO_UTF8 with the explicit .toUtf8().constData() call, particularly as some changed code uses that or constData() already.

I'd probably also like to see a variant of QTStr that accepts a QString and a renaming of QTStr itself as that function name is incredibly uninformative, but those two can wait for another PR.

PatTheMav · 2025-09-25T18:50:14Z

frontend/utility/YoutubeApiWrappers.cpp

 	lastErrorReason.clear();
-	const QByteArray url = YOUTUBE_LIVE_CHANNEL_URL "?part=snippet,contentDetails,statistics"
-							"&mine=true";
+	const char *url = YOUTUBE_LIVE_CHANNEL_URL "?part=snippet,contentDetails,statistics"


Use std::string_view instead of raw char pointers in C++ (prefer C++ types over C types).

Notably string views can also be static constexpr and either be resolved at compile time or (when reaching to their underlying character data via .data()) become read accesses into the data region (no allocations).

gxalpha · 2025-09-25T22:15:17Z

Looks good overall, I'd prefer if we could replace use of QT_TO_UTF8 with the explicit .toUtf8().constData() call, particularly as some changed code uses that or constData() already.

I actually have a branch already to at least get rid of = QT_TO_UTF8 patters (which all implicitly cast to std::string cause otherwise they'd be in big trouble as you can't keep that pointer). It's already tested from my side, I just need to open the PR. Getting rid of QT_TO_UTF8 completely is on my dream list as well. These changes-everywhere PRs are just quite a bit of work to test because I like to check every codepath separately.

Use std::string_view instead of raw char pointers in C++ (prefer C++ types over C types).

Will change that.

PatTheMav · 2025-09-26T15:21:11Z

Looks good overall, I'd prefer if we could replace use of QT_TO_UTF8 with the explicit .toUtf8().constData() call, particularly as some changed code uses that or constData() already.

I actually have a branch already to at least get rid of = QT_TO_UTF8 patters (which all implicitly cast to std::string cause otherwise they'd be in big trouble as you can't keep that pointer). It's already tested from my side, I just need to open the PR. Getting rid of QT_TO_UTF8 completely is on my dream list as well. These changes-everywhere PRs are just quite a bit of work to test because I like to check every codepath separately.

Great job, let's do that in a separate PR then. 💪🏻

gxalpha added 3 commits August 30, 2025 22:27

frontend,shared: Replace and disable QByteArray to char * casts

71df6ce

frontend: Replace and disable QString to QUrl casts

560202b

gxalpha requested a review from RytoEX August 31, 2025 12:05

gxalpha added the Code Cleanup Non-breaking change which makes code smaller or more readable label Aug 31, 2025

gxalpha force-pushed the qt-strict branch 3 times, most recently from 6a296f8 to 1f87d4d Compare August 31, 2025 16:56

gxalpha added 2 commits August 31, 2025 19:20

frontend,shared: Replace and disable contextless connect calls

a13ee91

gxalpha force-pushed the qt-strict branch from 1f87d4d to c115efc Compare August 31, 2025 17:20

RytoEX self-assigned this Sep 2, 2025

PatTheMav reviewed Sep 25, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

frontend: Enable Qt strict mode #12567

frontend: Enable Qt strict mode #12567

gxalpha commented Aug 31, 2025

Uh oh!

tytan652 commented Aug 31, 2025 •

edited

Loading

Uh oh!

gxalpha commented Aug 31, 2025

Uh oh!

tytan652 commented Aug 31, 2025 •

edited

Loading

Uh oh!

gxalpha commented Aug 31, 2025

Uh oh!

Penwy commented Aug 31, 2025

Uh oh!

RytoEX commented Sep 2, 2025

Uh oh!

PatTheMav left a comment

Uh oh!

PatTheMav Sep 25, 2025

Uh oh!

gxalpha commented Sep 25, 2025

Uh oh!

PatTheMav commented Sep 26, 2025

Uh oh!

Uh oh!

Uh oh!

frontend: Enable Qt strict mode #12567

Are you sure you want to change the base?

frontend: Enable Qt strict mode #12567

Conversation

gxalpha commented Aug 31, 2025

Description

Motivation and Context

How Has This Been Tested?

Types of changes

Checklist:

Uh oh!

tytan652 commented Aug 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gxalpha commented Aug 31, 2025

Uh oh!

tytan652 commented Aug 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gxalpha commented Aug 31, 2025

Uh oh!

Penwy commented Aug 31, 2025

Uh oh!

RytoEX commented Sep 2, 2025

Uh oh!

PatTheMav left a comment

Choose a reason for hiding this comment

Uh oh!

PatTheMav Sep 25, 2025

Choose a reason for hiding this comment

Uh oh!

gxalpha commented Sep 25, 2025

Uh oh!

PatTheMav commented Sep 26, 2025

Uh oh!

Uh oh!

tytan652 commented Aug 31, 2025 •

edited

Loading

tytan652 commented Aug 31, 2025 •

edited

Loading