fix(loader): set WA_TranslucentBackground before winId() to avoid opaque plugin backgrounds on Qt >= 6.11

[svan71]

Summary

On Qt 6.11, every dock tray plugin renders its background rectangle permanently — the hover highlight is drawn at all times instead of only on mouse-over. The rectangle picks up colour from whatever shows through from the desktop behind the dock. Expected behaviour (and the behaviour on Qt 6.8) is a fully composited, invisible background until the item is hovered.

The cause is attribute-vs-window-creation ordering in PluginItem::init().

Note: this PR depends on #477 to build. plugins/application-tray does not configure on Qt 6.11 without it, so CI here may fail to build the tray plugin until #477 lands. #477 is a one-line, build-only change.

Root cause

src/loader/pluginitem.cpp:

void PluginItem::init()
{
    winId();                                      // forces native window creation
    setAttribute(Qt::WA_TranslucentBackground);   // too late
    ...
}

winId() forces creation of the underlying native window. Qt::WA_TranslucentBackground must be set before that window is created, because it selects the surface/visual format (an ARGB visual). Setting it afterwards leaves the already-created surface opaque.

This is latent on Qt 6.8 — the version Deepin 25 currently ships (libQt6Core.so.6.8.0) — and becomes visible on Qt 6.11, where the window's surface format is finalized more strictly at creation time.

This is consistent with the prediction already recorded in this file's own comment, added in #383:

This might also happen on later Qt releases ... than the version deepin 25 currently uses (Qt 6.8.0)

Fix

 void PluginItem::init()
 {
+    setAttribute(Qt::WA_TranslucentBackground);
     winId();
-    setAttribute(Qt::WA_TranslucentBackground);

Reproduction

• Arch Linux, Qt 6.11.1, DDE on X11, master @ b3d4784 (2.0.36). Also reproduced on 2.0.35.
• Tray plugins draw their background rectangle at all times, not only when hovered. The rectangle is lighter than the dock and visibly tinted by the desktop wallpaper behind it.
• Affects the plugins that go through PluginItem — observed on the power button, the circled-arrow applet, the sound applet, and the clock. The collapse chevron and the sliders applet are unaffected, presumably being rendered by the dock's own QML rather than by the loader.
• Not reproducible on a Deepin 25 reference install (Qt 6.8.0) on identical hardware.

Testing

Verified by A/B on one machine against master @ b3d4784 (2.0.36), Qt 6.11.1, CMake 4.3.4, X11 — same session, same dock, wallpaper and theme unchanged, swapping only /usr/lib/trayplugin-loader and restarting dde-shell-plugin@org.deepin.ds.desktop.service dde-shell@DDE.service:

Binary	Contents	Idle (pointer off the dock)
sha256:fc782029…	2.0.36 + #477 only	rectangles present on power, circled-arrow, sound, clock
sha256:28c88c7e…	2.0.36 + #477 + this patch	no rectangles anywhere

Pristine 2.0.36 cannot be configured on Qt 6.11 at all, so the "before" binary is 2.0.36 + #477. That change touches only find_package, so it is a faithful stand-in for stock runtime behaviour. The two binaries differ, confirming the reorder is not elided by the optimizer.

The hover highlight still works with the patch applied: with the pointer resting on an XEMBED tray applet, only that one icon draws its rectangle and its tooltip appears, while every other tray item stays clean. This rules out the trivial false pass where the highlight is simply never drawn at all.

Legacy tray plugins exercised: onboard, shutdown, sound, and an XEMBED nm-applet.

Confirmed in both directions that the running loader processes had the expected binary mapped, by hashing /proc/<pid>/exe rather than trusting the on-disk file. (The loader rewrites its own argv to tray plugin: <name>, so pgrep -f trayplugin-loader finds nothing — match on /proc/*/exe instead.)

Caveat

This patch deliberately leaves the QWidget::paintEvent(event) call added by #383 intact — only the two-line reorder is changed. I have not been able to test on the openSUSE configuration that #383 targeted, so I cannot positively confirm no regression there. Leaving that call in place should be the safer direction, but a reviewer familiar with #383 may want to check.

References

• Depends on build: request Qt CorePrivate/WidgetsPrivate components in application-tray #477 (build fix; required to configure application-tray on Qt 6.11)
• Related: fix: render residue on openSUSE #383 (openSUSE dock plugin rendering artifacts) — introduced the paintEvent transparent fill and the comment predicting this failure on newer Qt

[sourcery-ai]

Sorry @svan71, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: svan71

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[deepin-ci-robot]

Hi @svan71. Thanks for your PR.

I'm waiting for a linuxdeepin member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.