fix(tray): only rebuild the Linux tray menu when its content changed - #11023

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

I reproduced the before/after table independently (Qt 6.10.2, CI container, offscreen):

• pr-11023 (b924956): 8 passed, 0 failed.
• master (ea11deb) with only the PR's test file applied: 7 passed, 1 failed — openingUnchangedMenuKeepsActions fails at 'firstAction' returned FALSE (testtrayaccountmenuqt.cpp:198), matching the description.

So the regression test fails before and passes after, as claimed. Note that openingAfterAccountChangeRebuildsMenu passes on master too: it is a guard against skipping a needed rebuild, not a red test. That's fine, but it is worth saying so in the description.

One non-blocking observation from reading the code (not covered by a test I ran): trayMenuStateKey() serializes every role with QJsonDocument::fromVariant, which silently turns types it cannot represent (e.g. a future QImage/QIcon role) into null, so such a change would not invalidate the key. All current roles I looked at are strings/URLs/bools, so it works today.

(Run with Claude Code assistance; results reviewed by me.)

@maksimtech Thanks for taking the time and reproducing it! Both points are addressed in the updated commit (ce6d797):

• The description now says openingAfterAccountChangeRebuildsMenu is a guard against skipping a needed rebuild, not a red test (also noted in the test).
• The state is no longer serialized to JSON. trayMenuState() keeps it as a QVariantList and compares it with QVariant::operator==, like ActivityListModel::refreshPreviewData() does. A value whose type can't be compared now never compares equal, so it causes a rebuild instead of a stale menu, and openingUnchangedMenuKeepsActions would catch that in CI.

Re-ran TrayAccountMenuQtTest on the new commit (Qt 6.11.2): 8 passed, 0 failed. Re-measured in the GNOME VM (34.0.4, AppIndicator v64): still 0 LayoutUpdated per opening, item ids unchanged.

(Changes made with Claude Code assistance; reviewed and tested by me.)

Which Model of Claude Code you use? I use Opus 5.5. @EagleEyeElite

@maksimtech Yes, I use Opus 5.5 as well. It's also in the commit's Assisted-by trailer.

@EagleEyeElite is written only Claude Code without model used

@maksimtech Not sure if we talk past each other. I mean the commit message itself in ce6d797

**fix(tray): only rebuild the Linux tray menu when its content changed**
...

Assisted-by: ClaudeCode:claude-opus-5-5
Signed-off-by: Conrad Klaus <conrad.klaus@outlook.de>

I am not sure if it's mandatory or advised to write the used model in the PR itself as well.
If I am missing something, I am glad to update the PR.

Thanks!

I am not sure if it's mandatory or advised to write the used model in the PR itself as well.

it is mandatory.
how you did it is correct, thank you :)