Qt 6 migration: fix remaining API compatibility issues and improve Wayland support#3779
Qt 6 migration: fix remaining API compatibility issues and improve Wayland support#3779josejl1987 wants to merge 4 commits intobaldurk:v1.xfrom
Conversation
josejl1987
force-pushed
the
qt6
branch
13 times, most recently
from
f96bdba to
24cf49a
Compare
This commit consolidates all fixes required for Qt 5 and Qt 6 compatibility across Linux and Windows platforms. Linux Qt 5 build fixes: - Add __has_include guard for wayland-client.h to skip when unavailable - Replace memcpy with reinterpret_cast for non-trivial ResourceId type - Guard palette().windowText() vs palette().foreground() API change Windows/Qt5 build fixes: - Fix Matrix4f::Zero() memset error for non-trivial type - Fix QBasicAtomicInteger::store() for Qt5 (single argument, no memory_order) - Fix QVariantList conversion in GLPipelineStateViewer exportHTMLTable - Fix C4457 variable shadowing warnings in EventBrowser and GLPipelineStateViewer - Add pragma warning disable for Qt 6 qHash size_t to uint conversion Qt 6 compatibility fixes: - Move Q_OBJECT macro to public section for proper MOC processing - All Qt version-specific APIs properly guarded with QT_VERSION checks All changes tested and verified to build successfully on both Qt 5 and Qt 6.
Consolidate verbose pragma warning comments into concise form. Remove explanatory comments for self-evident MSVC directives.
|
I am closing this PR for a few reasons. The first is that a large architectural change like this with significant impact on all platforms and the project direction are not something I will accept from a PR with no prior notice or discussion. This would require buy-in and co-operation from maintainers from the start to ensure it is a desired direction for the project. Secondly and more directly to that point there are currently no plans to support Qt 6 in the codebase. Not having looked at the code in detail the implications of trying to supporting both seems quite unappealing so this would only be something investigated if a move entirely to Qt 6 was considered. Note that this is also too large as a single PR and exceeds the guideline of ~1000 lines changed in the contributing documentation. As an additional point, there is nothing currently in the contributing or code of conduct addressing this but I will be adding a rule requiring zero use of LLMs in any way when writing code for RenderDoc PRs. Throughout the huge number of pushes to the branch I could see that you were using Claude for this PR, though you have hidden that fact from the final commits as of the time of writing. |
|
Fair enough, I was just testing if Qt 6 alone would fix the Wayland issues, that's why I left it as draft. Sorry if I caused you any inconvenience, for sure it was not my intention to get something like this merged without discussion. And as I said in the issue thread, Qt 6.10 still has lots of issues with Wayland, so certainly it is not worth migrating anything. However, I think that part of this can be used to have proper Wayland capture on Qt 5. That should be a much simpler PR. |
|
Draft PRs are a pointless anti-feature of github for this reason and I wish they could be disabled - either the code should be reviewed, in which case the draft status is nonsense, or you are working a branch that shouldn't be reviewed in which case creating a PR is unnecessary at best and causes noise/confusion at worst. You can of course have a branch on a fork which you make whatever changes to you want for your own local version. |
2 participants
Description
This PR introduces support for building qrenderdoc with Qt 6, while maintaining backward compatibility with Qt 5, partially addressing #853
Key Changes
Qt 6 Support: Updated CMakeLists.txt and qmake project files (qrenderdoc.pro) to detect and use Qt 6 if available.
Code Compatibility: Implemented conditional compilation to handle API differences between Qt 5 and Qt 6. This includes replacing deprecated classes like QTextCodec with QStringDecoder and QStringConverter when building with Qt 6.
Wayland Enablement: Enabled the experimental ENABLE_UNSUPPORTED_EXPERIMENTAL_POSSIBLY_BROKEN_WAYLAND option and added linking against wayland-client to support explicit sync detection on Wayland.
Cleanups: Addressed various deprecated API warnings and minor build fixes.
Motivation
Qt 6 is the current LTS version and is becoming the default on many modern Linux distributions, and makes Wayland capture more stable.
This update ensures RenderDoc can be built and run in these environments. However, in some compositors, it still doesn't work nicely, so there's an automatic fallback to XWayland for QRenderdoc.
So far, it doesn't seem to affect the capture of Wayland applications, although I would say we need to test more thoroughly.