Suppress, disable, or limit number of Ubuntu system notifications

[SteveMacenski]

Hi,

When I'm doing some rapid prototyping, I'm often building, testing, changing, building, testing, ... and can easily build hundreds of times over a few days. Also in a more typical workflow, I don't power cycle my machine more than once every couple of months so some of the "garbage" can pile up.

The "colcon build complete" notification badges can be helpful, but they also pile up. There has been a point that the notifications have built up to such a point that trying to clear them will lock up my system indefinitely.

I would like to propose either disabling the notifications (probably not the right move), suppressing them from being kept in the persisting notifications bar (e.g. Spotify will tell me song it changed to but there's no long term log of those in my notifications bar), or limit the number of colcon messages that can be kept at any given time to something more manageable.

[christophebedard]

I would also support either limiting the number of notifications or sending temporary notifications (like Spotify).

[SteveMacenski]

Some quick experimenting shows that self._last_notification.close() will close the notification in the notification bar as well as on screen. Though from a glance, update() should replace the existing notification not add a new one. Perhaps there's multiple instances of this floating around for each build attempt, unclear to me from some quick prototyping.

[dirk-thomas]

Please see #31 about how to disable the specific extension.

Afaik while the notify2 / dbus API has a timeout parameter (see https://notify2.readthedocs.io/en/latest/#notify2.Notification.set_timeout and https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-latest.html#basic-design) the documentation explicitly says:

This is a request, which the server might ignore.

And on Ubuntu (Focal) it is not being respected based on my observation.

Afaik there is also no way to close previous notifications through the API (assuming the process which created the notification has ended and therefore the handle it had isn't available).

[SteveMacenski]

From an ipython session, the timeout parameter doesn't work, as you mention, its just being ignored. But the close() does work.

e.g.

import notify2
notify2.init('blah blah blah')
x=notify2.Notification("hi", message="bye")
x.set_timeout(1000) 
x.show() #fails
x.timeout = 1000
x.show() #fails
x.close() #works

[dirk-thomas]

But you can only invoke close() from within the process which has the handle. Assuming you invoked colcon and want to see the message for 1 min. than that would require that the invocation doesn't exit but remain running for that duration.

[SteveMacenski]

You must run into this alot, but this isn't how I expected my afternoon to go... but I found the solution.

The notifications spec does properly handle some hints. It happens to actually implement the transient hint which when set to True will not persist on the system [1]. So we can make a trivial update of the following to enable:

self._last_notification.set_hint('transient', True)

You can verify with the following:

import notify2
notify2.init('catkin why not')
x=notify2.Notification("hi", message="you better not stick around here, buddy")
x.show() # persists, clear it
x.set_hint('transient', True)
x.show() # no longer persists

[1] https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-latest.html#hints
[2] PR: #46