notify-send(1) can't replace an existing notification

Bug #257135 reported by Ralph Corderoy on 2008-08-11
This bug affects 51 people
Affects Status Importance Assigned to Milestone
libnotify (Debian)
libnotify (Ubuntu)

Bug Description

Binary package hint: libnotify-bin

Ubuntu 8.04, libnotify-bin 0.4.4-3build1.

notify-send(1) is very useful but it doesn't tell me the notification ID that's been created, nor does it let me specify that to replace an earlier notification. See, in particular the replaces_id parameter and the return value.

I'd like to be able to use it something like

    id=$(notify-send --show-id foo)
    sleep 60
    notify-send --replace $id bar

This would be great for long-running shell scripts that are monitoring something.

cnom (cnom) wrote :

This would me wildly useful. Something for the wish list?

Changed in libnotify (Ubuntu):
status: New → Confirmed

I consider it a bug that the underlying mechanism returns an ID and allows for its replacement yet the userspace command doesn't. It's restricting the usefulness of the mechanism.

quequotion (quequotion) wrote :

It would be really nice to have command line access to this parameter.

There are nearly as many use-cases for this as there are for using notify-send at all.
This would enable easily scripted messages to update status quickly. As it is, to get messages at the speed of channel surfing, temperature changes, bandwidth use, etc, etc, etc it's necessary to set an arbitrary, system-wide timeout of 1sec with notifyconf ("Notify-OSD Configuration" utility available from ppa) and set --expire-time < 1000. (This makes a notification which blinks in and out of existence.)

Case in point: I'm using notify-send for some scripts that change tv channels and volume. It would be unnecessarily complicated to write and compile a program to do these things, and since I am using a shell script I can't avoid waiting for one message to disappear before the next appears.

To be precise I want to do this:

notify-send --replaces_id=tvvolume --icon=gtk-info --urgency=critical --expire-time=999 "Volume" "`v4l2-ctl -C volume`

I imagine this command would set the id for the first notification to "tvvolume" and replace that with other notifications that have the same id.... Of course an implementation on par with gnome's volume indicator would be best, but before that I have another long list of feature requests.

Changed in libnotify (Ubuntu):
importance: Undecided → Low
cometdog (ericctharley) wrote :

@ Sebastien Bacher

I want to disclose up front that I really don't know the details of how bug importance is assigned, or what it really means for this to be "Low" importance.

That said, it does look like you have looked at bug #390508 (I see that you responded there), which many people have been quite vocal and upset about. In my opinion fixing this bug (#257135) in notify-send so that it can replace notifications would solve many people's problems on #390508. That is, I think it would solve the underlying issue for those who want to be able to specify a shorter timeout. With that in mind, would it be reasonable to increase the importance to something higher than "Low?" My concern is that if it is rated "Low" it may never really get worked on.

Martin Sander (forke) wrote :

hack something together in ruby/python/<insert_other_script_language_of_choice_with_dbus_support_here>.

As I have done here:
(probably not idiomatic Ruby, I know much more Python and Perl..). Maybe I will add the missing stuff so that it is fully backward-compatible to notify-send and can work as a drop in. Maybe I won't.

You can't pick the ID yourself, you have to take the one that the notification-daemon sends back via dbus. It's an INT32, so "tvvolume" won't be possible.

quequotion (quequotion) wrote :


How can you know what that number is?

Paul Collins (pjdc) wrote :

Here's a patch to notify-send.c that adds --print-id and --replace-id switches.

I've tested it lightly here and it seems to do what I expect.

Paul Collins (pjdc) wrote :

Here's v2 of the patch, which now terminates the argument list to g_object_set correctly.

Thanks Paul. Why might there not be an id to print?

Paul Collins (pjdc) wrote :

Hi Ralph,

Actually, I don't know if that can happen. And even if the ID is 0, we should print it anyway, because, as I discovered when I was updating my scripts, we can then safely write

while ...; do
    id=$(notify-send -p -r $id ...)

which is nice and simple.

Attached is v3 of the patch with the check removed.

The attachment "notify-send.c: add --print-id and --replace-id switches" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Mateo Salta (mateo-salta) wrote :

It would be nice to know how to use the patch, where notify-send.c is to be placed...

Mateo Salta (mateo-salta) wrote :

Ok, I figured it out, copy the patch text, save as "patch". download source, , un-archive the source, put "patch" in the source folder, patch with `patch -p1 < patch` in terminal in the folder, then



`sudo make install`

If that is too complipacated, someone at IZX at AskUbuntu made a ppa with the patch applied:

Changed in libnotify (Debian):
status: Unknown → New
Colin Hemming (b-ubuntuone14) wrote :

I would find this incredibly helpful, but would also love to be able to also dismiss something by ID. That way a "Processing..." notification could be displayed indefinitely, then removed when the process behind completed.

As someone seems to have already patched this it would be fantastic to see it deployed in the official repositories, rather than having to muck about compiling my own version!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.