service-discovery-applet displays too many notifications

[David Barth]

Binary package hint: service-discovery-applet

service-discovery-applet uses libnotify and may display too many notifications, for example on a large network with numerous agents.

See https://bugs.launchpad.net/notify-osd/+bug/333517/comments/10

[Noel J. Bergman (noeljb)]

This came from Bug 333517, where I had asked commented about the absolutely incessant and irritating problem where with service-discovery-applet, the notice window is almost CONSTANTLY showing up to indicate what services appear and disappear? I don't so much mind the notifications as I do that they are in a highly crucial part of the screen, rather than out of the way.

I am attending a conference and, using it as an example, notify-osd has already been active for the past hour quite literally non-stop. Rather annoying when it is sitting over the titlebar and tab area of browsers and apps, despite the fact that it will fade when mouse hovers. So much for being unobtrusive.

Mind you, I'm not sure that the service-discovery-applet is at fault. What else should it do, other than provide filters, when services come and go?

[Pedro Villavicencio (pedro)]

confirming, thanks for the report.

[Noel J. Bergman (noeljb)]

FWIW, I've switched back to Intrepid to test, and despite having the same volume of notifications, which are both valid and may be desirable, they are *far* less intrusive because they are in the bottom right of the screen, and do use the x y hinting mentioned in Bug 333517.

By the way, if anyone IS going to work on service-discovery-applet, we have an outstanding patch to fix the long-standing VNC problem. I posted many months ago, and have tried to get it upstream as well.

[David Barth (dbarth)]

Noel J. Bergman wrote:
> This came from Bug 333517, where I had asked commented about the
> absolutely incessant and irritating problem where with service-
> discovery-applet, the notice window is almost CONSTANTLY showing up to
> indicate what services appear and disappear? I don't so much mind the
> notifications as I do that they are in a highly crucial part of the
> screen, rather than out of the way.
>
> I am attending a conference and, using it as an example, notify-osd has
> already been active for the past hour quite literally non-stop. Rather
> annoying when it is sitting over the titlebar and tab area of browsers
> and apps, despite the fact that it will fade when mouse hovers. So much
> for being unobtrusive.
>
> Mind you, I'm not sure that the service-discovery-applet is at fault.
> What else should it do, other than provide filters, when services come
> and go?
>
You said it all:
 * provide filters
 * buffer some events, so that instead of telling you 100 times that a
new service is available, it would tell you that 100 similar services
are available
 * detect harder when services are unstable (toggling between available
/ unavailable)

There is a similar scalability issue with printers: on a large
enterprise network, you may be spammed every morning by notifications
from new available printers.

Matthew: thought?

[Noel J. Bergman (noeljb)]

 * provide filters

That's fine, and would be very useful, since people might care about some, but not all, services. Or services only on specific hosts, not all hosts.

 * buffer some events so that instead of telling you 100 times that a
   new service is available, it would tell you that 100 similar services
   are available

There are classes of service for which the word "similar" does not apply because it is the specific instance that matters. I'd suggest seeing if filtering can handle this issue before attempting to discard notifications based solely on buffering out similar service types.

Filtering could be on service type, service name, host name, host IP, subnet, etc.

[Noel J. Bergman (noeljb)]

David, to be clear, you do know that filtering by service type already exists in the code, right? That is one of the three configuration options that do exist, along with whether or not to provide notifications and whether or not to ignore local services.

In Bug 33517, Mark Shuttleworth suggests that we have the applet use append mode. There is only one call in the code for doing notification:

    def display_notification(self, title, message, iconfile = "file:///usr/share/service-discovery-applet/icons//48x48/service-discovery-applet.png"):
 try:
     if self.show_notifications == True:
                n = pynotify.Notification(title, message, iconfile)
# x,y = self.applet.window.get_origin()
# n.set_hint("x",x)
# n.set_hint("y",y)
# n.attach_to_widget(self.applet.window)
                n.show()
 except:
     print "can't use notification daemon"
            pass

The hinting code is commented out in both Intrepid and Jaunty, so no change there. If I understand Mark's suggestion, the correct change would be:

# diff -u service-discovery-applet~ service-discovery-applet
--- service-discovery-applet~ 2008-06-12 08:18:07.000000000 +0200
+++ service-discovery-applet 2009-03-26 03:06:43.000000000 +0100
@@ -249,6 +249,7 @@
 # n.set_hint("x",x)
 # n.set_hint("y",y)
 # n.attach_to_widget(self.applet.window)
+ n.set_hint("x-canonical-append", "allowed")
                 n.show()
  except:
      print "can't use notification daemon"

I've made the change locally, and will try it out.

[Noel J. Bergman (noeljb)]

No, that won't work (spacing error in the paste and the change to set_hint_string aside). Append mode just does not work properly, as I have found documented in Bug 337394, which prevents the code from working. Details to follow on that bug entry.

[Noel J. Bergman (noeljb)]

OK, I am submitting an patch for people to try.

This patch does not use append mode, for several reasons. Firstly, and least importantly, append mode is currently broken (does not merge bubbles from the same submitter with the same title). Secondly, and more importantly, append mode is limited to 10 lines, which seems inadequate for our purpose. Thirdly, append mode effects only the text, not the icon, and we do use different icons for each service.

HOWEVER, what you will see will depend upon the arrival rate of notifications, because the code uses a single notifier, and updates it as notifications arrive. Since the service-discovery-applet provides a menu in which you can see the current state, that seemed "OK", although I'd prefer to see more notices, so further tweaks are ripe for consideration.

[Noel J. Bergman (noeljb)]

I added a time.sleep(0.5) after the show, and with that, you can see the series of services as they appear and disappear.

[Noel J. Bergman (noeljb)]

Uh guys? Can we get this patch applied? Without it on Karmic, I get the discovery started notice but no notices of services being discovered at that point. With it, the service notifications appear.

[Noel J. Bergman (noeljb)]

Correction on that last item. The problem is in service-discovery-applet, itself. It discards all notifications from the first second of operation. Fixed by the attached. Arguably, discarding notification at start up prevents flooding when the system is first booted, but then the same could be said of resuming from suspend or hibernate.

[Noel J. Bergman (noeljb)]

OK, this revisits https://bugs.launchpad.net/ubuntu/+source/service-discovery-applet/+bug/348377/comments/6 and Mark Shuttleworth's suggestion in Bug 33517 that we have the applet use append mode.

Previously, this did not work because append mode did not work (Bug 337394). Now that it works, the original idea can be deployed. Attached is a revised version of the patch to change from single notifications to appended notifications. It also changes the title language slightly to account for the fact that there might be multiple services involved.

Previously, I had noted three (3) issues with using append. The first not longer applies, since append works. On the second, we can probably make due with the fact that append mode is limited to 10 lines, since it does visually indicate that messages have scrolled (user can check the menus), and we can live with the fact that append mode effects only the text, not the icon, and we use different icons for each service.