stack tag notifications do not use the new icon
Hey, basically if the provided icon of a icon file is updated next notifications will use the old icon
How to reproduce
- no change to config is needed
- use a file as a example for icon file and run:
$ notify-send -h string:x-dunst-stack-tag:test -i tmp.jpg "123"
- change the
tmp.jpgfile - as long as the last notification is visible on screen run the same command for sending notification and see the previous icon is shown
System information
dunst version: 1.12.2 (2025-03-05)
Linux distro: Archlinux
Hello thanks for pointing this out. Is this a regression or was this introduced in the new dunst version? Also does notify-send beahve differently than dunstify?
@bynect I don't know it's a regression just recently find out about stack tag and notify-send and dunstify behave similarly
I can reproduce this issue. it is very strange that it happens only when the stack tag is set. I will investigate
it seems to be caused by the way that tagged notifications are treated, which is different than normal duplicates
I found the cause. it is in the way icons are compared that checks just the path name. I will try to come up with a solution without compromising performance
if you want to try I changed the way duplicate icons are checked in #1473
if you want to try I changed the way duplicate icons are checked in #1473
I'm trying this PR out and can confirm new icons are replaced correctly this is the script being used
I'm still getting this issue on version 1.13, which should have included this fix. It works for icons in the icon theme, but for specified paths to icons it keeps the old one. However if I send with a path, then from the icon theme, and then another from the theme, it updates (see screen rec)
An icon from the theme can also be replaced by a specified path, that way round works, just from the specified path to anything else doesn't.
https://github.com/user-attachments/assets/ac309fb9-cd9e-4744-8814-6227d7b29987
I can also reproduce.
send theme icon -> ok send img path -> ok send theme again -> nothing send theme another time -> changes
thanks for the report
Hello thanks for pointing this out. Is this a regression or was this introduced in the new dunst version? Also does notify-send beahve differently than dunstify?
Does not happen on <= 1.12.x, using this for testing in 1.13.0 (2025-08-04):
icon1="${HOME}/.config/hypr/scripts/assets/volume-high.svg"
icon2="${HOME}/.config/hypr/scripts/assets/volume-low.svg"
dunstify -h string:x-dunst-stack-tag:test -i "$icon1" "test1"
sleep 1
dunstify -h string:x-dunst-stack-tag:test -i "$icon2" "test2"
On 1.12.x this will have different icons as expected, on 1.13.0 it shows the same icon. Funnily enough this does not happen on 1.12.2 (2025-03-05).
Well, seems like trying to fix the original issue created another one. I will look into it
Should I open a new issue? They are basically the same "issue" but a tiny bit different.
it's fine, I already reopened it. hopefully it should not be a big fix
@winkelnp @v4n00 do you think the way I fix this in #1521 is sensible?
Seems sensical to me, though I am very much less than familiar with the code base. I've tested on my machine and it seems to work (at least sending multiple stacking notifications with different specified-path icons does). Happy to test any other scenarios if you'd like?
Seems sensical to me, though I am very much less than familiar with the code base. I've tested on my machine and it seems to work (at least sending multiple stacking notifications with different specified-path icons does). Happy to test any other scenarios if you'd like?
you could try using the same file but changing it. so:
-
start notification with img.png
-
modify / rename img2.png to img.png
-
send another notification with img.png
this should correctly display the new img
Does the trick :)
Does the trick :)
Nice. I will merge 👍