D24667: Activate when both associatedWidget and menu are null

[Konrad Materka]

kmaterka added a comment.


  This fixes issue from first comment <https://bugs.kde.org/show_bug.cgi?id=365105#c6> made by @davidedmundson . Second <https://bugs.kde.org/show_bug.cgi?id=365105#c7> 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?

REPOSITORY
  R289 KNotifications

REVISION DETAIL
  https://phabricator.kde.org/D24667

To: kmaterka, davidedmundson, broulik, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191015/edc5071e/attachment.html>