Dunst: Dunst doesn't respect `-r` (replace) anymore

Created on 24 Nov 2018 · 4Comments · Source: dunst-project/dunst

I have fetched the latest version of Dunst today and built it. It seems that the replace functionality is not working anymore although it was working before perfectly.

$ dunstify -r 2593 -p "test volume"
13
$ dunstify -r 2593 -p "test volume"
14
$ dunstify -r 2593 -p "test volume"
15

It seems that it no longer replaces the previous id and my volume notifications are stacking up on top of each other. As it's showed in the snippet every time it runs, A new id is generated and doesn't respect the -r $id anymore.

The last working commit is: f0b047497eabf3, so whatever has caused this issue is in the following commit that was merged on 2018-11-11:

d879d70da060ea 2018-10-25 12:32 +0200 Jordan Galby Implement stack_tag, implementing x-canonical-private-synchronous

Before this commit the result of the above snippet was as expected:

$ dunstify -r 2593 -p "test volume"
2593
$ dunstify -r 2593 -p "test volume"
2593
$ dunstify -r 2593 -p "test volume"
2593

Installation info

Version: Dunst - A customizable and lightweight notification-daemon v1.3.2-235-gd786381
Install type: manually
Distro and version: Ubuntu 18.04.1 LTS x86_64

Bug

Source

existme

All 4 comments

The fix is already included in #551. So before release we'll have this fixed.

But anyway, while you're here, checkout the stack_tag feature, which is much nicer than a random ID, which actually doesn't exist.

bebehei on 24 Nov 2018

👍1

Thank you for the quick feedback. However, I couldn't find documentation regarding stack_tag.
I have added this section to dunstrc:

[volume]                                                                         
    appname = volume                                                             
    history_ignore = yes                                                         
    foreground = "#ebdbb2"                                                       
    set_stack_tag = "volume"

Is this enough, what would be the other benefits of such feature? or it's just a way for replacing random ids as you said.

existme on 24 Nov 2018

@existme There's not much documentation on it, you're right, but that example is pretty much it: Notifications with the same tag replace each-other. As you said, it's intended to resolve this exact usecase without using random ids that can potentially conflict with other notifications.