D26604: Check if there is an activatable service when notification service owner changes

Nicolas Fella noreply at phabricator.kde.org
Sun Jan 12 15:36:23 GMT 2020


nicolasfella created this revision.
nicolasfella added reviewers: Plasma, broulik.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
nicolasfella requested review of this revision.

REVISION SUMMARY
  At notification backend initialization we don't just check whether the notification service exists but also whether one could be activated and treat it as existant then.
  When the service owner changes (e.g. plasmashell is crashing) we check if a new service exists but not whether one could be activated. A notification coming in while plasmashell is crashed thus triggeres the horrible KPassivePopup fallback.
  
  plasmashell itself is not DBus activatable, but it has a waitforname helper that is and forwards the notification to Plasma. With this patch instead of using the fallback we DBus-activate the helper and the notification appears as soon as Plasma is restarted.

TEST PLAN
  - application is started and sends notification after plasma started: No change
  - application sends notification before plasma is started: No change, notification is shown as soon as Plasma starts
  - application sends notification with running plasma, then plasma quits, application sends another notification, plasma restarts: Second notification is shown as soon as plasma starts instead of creating KPassivePopup

REPOSITORY
  R289 KNotifications

BRANCH
  checkactivatable

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

AFFECTED FILES
  src/notifybypopup.cpp

To: nicolasfella, #plasma, broulik
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/20200112/03a1e27a/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list