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