This fixes issue from first comment made by @davidedmundson . Second is still not fixed. Let me copy it here:

We have one menu for the whole tray instance
We create and delete KSNI object in init() and cleanup() which are called on show() hide()

The SNI takes ownership of the menu

so for the the second init, we set the SNI to a now deleted menu.

The assumption in QPA is that context menu is persistent, tray icon is not.

There are few way to fix that, but I don't like any of these:

• create new QMenu when old one is destroyed, try to recover menu content
  • menu actions are stored safely in m_items, but title, icon and other flags are not
  • we can have two menus, one for KSNI, second to store values for recovery but this is silly
• create a proxy/delegate to internal QMenu, so that the internal QMenu won't be deleted
  • overkill? a lot of methods/signals/slots to delegate
• do not delete menu in KSNI
  • not possible, other apps are relaying on this behavior
  • add new parameter to skip menu deletion? Isn't it another overkill ad unnecessary API change?
• remove SystemTray support from KdePlatformTheme
  • easiest, but...
  • Qt has implementation based on DBus, but it behaves differently to KSNI: different position of context menu, different implementation of activated, scroll is not supported etc

What do you think?

I think the best would be to add additional parameter to KSNI. Change from:

void KStatusNotifierItem::setContextMenu(QMenu *menu);

to something like this:

void KStatusNotifierItem::setContextMenu(QMenu *menu, bool takeOwnership = true);

Then, after next release of Frameworks, change implementation in plasma-integration.

bool takeOwnership = true);

If only Qt/we used modern C++ features to communicate object ownership :)

Good rundown of the options.

remove SystemTray support from KdePlatformTheme

It's not trivial. There's no way to access the relevant Qt classes. I should revisit the patch that allowed that.

Our hopeful longterm plans for KF6 are to kill KStatusNotifierItem add the missing methods to QSystemTray, fix some other parts of their implementation and then drop it here.

do not delete menu in KSNI

Makes the most sense in some form.
It /could/ be done without additional API by abusing QObject parentship: https://phabricator.kde.org/P479

Then this code being a special case would just set the parent back afterwards. Whether that's actually any better than any explicit boolean method is debatable though.

In D24667#548245, @broulik wrote:

bool takeOwnership = true);

If only Qt/we used modern C++ features to communicate object ownership :)

Hehe, yes. Unfortunately KSNI messes with parent of menu object :/

do not delete menu in KSNI

Makes the most sense in some form.
It /could/ be done without additional API by abusing QObject parentship: https://phabricator.kde.org/P479

Then this code being a special case would just set the parent back afterwards. Whether that's actually any better than any explicit boolean method is debatable though.

Believe me, I checked that :) I was thinking about this, but it won't work in this form. There are two reasons. First:

void KStatusNotifierItemPrivate::init(const QString &extraId)
//...
QMenu *m = new QMenu(associatedWidget);

associatedWidget can be null or not. I don't know if this is needed, what is the purpose of this code and what are side effects. Probably this can be safely removed.
Second reason is more serious: QMenu parent must be of QWidget type and KSNI is not a widget.