Eu peguei a última versão do Dunst hoje e a construí. Parece que a funcionalidade de substituição não está mais funcionando, embora antes estivesse funcionando perfeitamente.
$ dunstify -r 2593 -p "test volume"
13
$ dunstify -r 2593 -p "test volume"
14
$ dunstify -r 2593 -p "test volume"
15
Parece que ele não substitui mais o id anterior e minhas notificações de volume estão se acumulando. Como é mostrado no snippet toda vez que é executado, um novo id é gerado e não respeita mais o -r $id
.
O último commit de trabalho é: f0b047497eabf3
, então o que quer que tenha causado esse problema está no seguinte commit que foi mesclado em 2018-11-11
:
d879d70da060ea 2018-10-25 12:32 +0200 Jordan Galby Implement stack_tag, implementing x-canonical-private-synchronous
Antes desse commit, o resultado do snippet acima era o esperado:
$ dunstify -r 2593 -p "test volume"
2593
$ dunstify -r 2593 -p "test volume"
2593
$ dunstify -r 2593 -p "test volume"
2593
Dunst - A customizable and lightweight notification-daemon v1.3.2-235-gd786381
manually
Ubuntu 18.04.1 LTS x86_64
A correção já está incluída em # 551. Portanto, antes do lançamento, teremos isso consertado.
Mas de qualquer forma, enquanto você está aqui, verifique o recurso stack_tag, que é muito melhor do que um ID aleatório, que na verdade não existe.
Obrigado pelo feedback rápido. No entanto, não consegui encontrar a documentação sobre stack_tag
.
Eu adicionei esta seção a dunstrc
:
[volume]
appname = volume
history_ignore = yes
foreground = "#ebdbb2"
set_stack_tag = "volume"
Isso é suficiente, quais seriam os outros benefícios desse recurso? ou é apenas uma maneira de substituir ids aleatórios, como você disse.
@existme Não há muita documentação sobre isso, você está certo, mas aquele exemplo é basicamente isso: notificações com a mesma tag substituem-se. Como você disse, o objetivo é resolver esse caso de uso exato sem usar IDs aleatórios que podem entrar em conflito com outras notificações.
Obrigado @tsipinakis pelo esclarecimento.