Adapt waiting for user notification facilities for Jessie
In 3f2e56a2c269d2a3d0cbf39b86c69276faf7d93b we introduce a lookup for the
notification-daemon process, which doesn't run in GNOME Shell. This needs to be adjusted.
Note that the pgrep we're using isn't fool-proof: anonym has seen at least one failure when the process was running already, but the notification wasn't shown.
Likely we need to check if the DBus service is ready instead.
Start adjusting waiting for notification facilities for Jessie.
It makes no sense to wait for gnome-panel on Jessie: we're not running
it anymore. Also, GNOME Shell is now providing the notification daemon
facility, so we don't need to wait for notification-daemon.
Will-fix: #8685 (Well, not really: as said there, this might not be robust
enough: best would be to check if the DBus service is ready instead.)
Wait for ibus-daemon instead of nm-applet, to judge whether we can send notifications.
We should not be running nm-applet on GNOME Shell, since this functionality is
nowadays taken over by GNOME Shell itself. And notifications are also handled by
GNOME Shell, so let's instead wait for a process that's started by GNOME Shell,
assuming that if it's ready enough to start long-lived child processes,
hopefully it's ready to receive and enqueue/display notifications.
Will-fix: #8685 (not really, but let's help Redmine track the relevant commits)
#13 Updated by intrigeri over 2 years ago
- Status changed from In Progress to Resolved
- Assignee deleted (
- % Done changed from 10 to 100
- Feature Branch set to feature/jessie
As reported on #8779, I've not seen issues about lost notifications on Jessie for a while, so I think that it's good enough to wait for
ibus-daemon as we're doing, and I'm closing this ticket. If we see issues about it again we can check for the D-Bus service as suggested above.