Project

General

Profile

Bug #8685

Adapt waiting for user notification facilities for Jessie

Added by intrigeri almost 3 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Spoof MAC
Target version:
Start date:
01/13/2015
Due date:
% Done:

100%

QA Check:
Feature Branch:
feature/jessie
Type of work:
Code
Blueprint:
Easy:
Affected tool:

Description

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.


Related issues

Related to Tails - Bug #8571: MAC spoofing failure doesn't result in panic mode (module removal) Resolved 01/06/2015
Related to Tails - Feature #10657: Factorize waiting for notifications Confirmed 11/24/2015
Duplicated by Tails - Bug #8779: Make start_notification_helper more robust Duplicate 01/22/2015

Associated revisions

Revision 88de98a1 (diff)
Added by intrigeri over 2 years ago

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.)

Revision 5771f243 (diff)
Added by intrigeri over 2 years ago

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)

History

#1 Updated by intrigeri almost 3 years ago

  • Related to Bug #8571: MAC spoofing failure doesn't result in panic mode (module removal) added

#2 Updated by anonym almost 3 years ago

  • Related to Bug #8686: Sometimes notification-daemon aborts, causing desktop notifications to not be displayed added

#3 Updated by intrigeri over 2 years ago

  • Related to Bug #8779: Make start_notification_helper more robust added

#4 Updated by intrigeri over 2 years ago

  • Status changed from Confirmed to In Progress

#5 Updated by intrigeri over 2 years ago

#6 Updated by intrigeri over 2 years ago

  • % Done changed from 0 to 10

#7 Updated by intrigeri almost 2 years ago

  • Related to deleted (Bug #8779: Make start_notification_helper more robust)

#8 Updated by intrigeri almost 2 years ago

  • Duplicated by Bug #8779: Make start_notification_helper more robust added

#9 Updated by intrigeri almost 2 years ago

dbus-send --print-reply --session --dest=org.freedesktop.Notifications /org/freedesktop/Notifications org.freedesktop.Notifications.GetServerInformation should be enough to tell us if something (in our case, GNOME Shell) is ready to handle notifications.

#10 Updated by intrigeri almost 2 years ago

  • Related to deleted (Bug #8686: Sometimes notification-daemon aborts, causing desktop notifications to not be displayed)

#11 Updated by sajolida almost 2 years ago

  • Blocks Bug #8040: Update notification screenshots in the documentation for Jessie added

#12 Updated by intrigeri almost 2 years ago

  • Blocks deleted (Bug #8040: Update notification screenshots in the documentation for Jessie)

#13 Updated by intrigeri almost 2 years ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (anonym)
  • % 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.

#14 Updated by intrigeri almost 2 years ago

  • Related to Feature #10657: Factorize waiting for notifications added

Also available in: Atom PDF