Issue description
Simply put: The history JSON provided by dunstctl history does not provide an urgency property. E.g., the current object for a history output is:
{
"body" : {
"type" : "s",
"data" : "Hyprland battery settings applied."
},
"message" : {
"type" : "s",
"data" : "<b>Battery Mode Activated</b>\nHyprland battery settings applied."
},
"summary" : {
"type" : "s",
"data" : "Battery Mode Activated"
},
"appname" : {
"type" : "s",
"data" : "hypr-power-handler.sh"
},
"category" : {
"type" : "s",
"data" : ""
},
"default_action_name" : {
"type" : "s",
"data" : "default"
},
"icon_path" : {
"type" : "s",
"data" : ""
},
"id" : {
"type" : "i",
"data" : 2
},
"timestamp" : {
"type" : "x",
"data" : 54834483
},
"timeout" : {
"type" : "x",
"data" : 3000000
},
"progress" : {
"type" : "i",
"data" : -1
}
}
I would expect to see something similar to "urgency" : { "type" : "s", "data" : "low" } here. Dunst does appear to have memory of the urgency, as indicated by the urgency appearance matching the message urgency when using dunstctl history-pop.
I can--and plan to for the moment--to work around this by keeping my own history file with all of the environment variables saved to JSON via dunst-fired script, but it does seem like it's something that should be included in the dunstctl history output. I could also make the same argument for DUNST_STACK_TAG and DUNST_URLS, though the exclusion of those didn't lead me to create a history workaround and submit this.
Installation info
Dunst - A customizable and lightweight notification-daemon 1.12.1 (2024-12-17)
Compiled on 2024-12-22 with the following options:
X11 support: enabled
Wayland support: enabled
SYSCONFDIR set to: /etc
Compiler flags: -g -std=gnu11 -pedantic -Wall -Wno-overlength-strings -Os -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/build/dunst/src=/usr/src/debug/dunst -flto=auto -pthread -MMD -MP
Linker flags: -lm -lrt -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto -lgio-2.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lcairo -lwayland-client -lwayland-cursor -lX11 -lXinerama -lXext -lXrandr -lXss
- Install type: Arch Package
extra/dunst
- Window manager / Desktop environment:
Hyprland 0.46.2 built from branch at commit 0bd541f2fd902dbfa04c3ea2ccf679395e316887 (version: bump to 0.46.2).
Date: Thu Dec 19 19:26:47 2024
Tag: v0.46.2, commits: 5566
built against:
aquamarine 0.5.1
hyprlang 0.6.0
hyprutils 0.3.0
hyprcursor 0.1.11
hyprgraphics 0.1.1
flags set:
debug
Minimal dunstrc
# This occurs on built-in config
Issue description
Simply put: The history JSON provided by
dunstctl historydoes not provide an urgency property. E.g., the current object for a history output is:{ "body" : { "type" : "s", "data" : "Hyprland battery settings applied." }, "message" : { "type" : "s", "data" : "<b>Battery Mode Activated</b>\nHyprland battery settings applied." }, "summary" : { "type" : "s", "data" : "Battery Mode Activated" }, "appname" : { "type" : "s", "data" : "hypr-power-handler.sh" }, "category" : { "type" : "s", "data" : "" }, "default_action_name" : { "type" : "s", "data" : "default" }, "icon_path" : { "type" : "s", "data" : "" }, "id" : { "type" : "i", "data" : 2 }, "timestamp" : { "type" : "x", "data" : 54834483 }, "timeout" : { "type" : "x", "data" : 3000000 }, "progress" : { "type" : "i", "data" : -1 } }I would expect to see something similar to
"urgency" : { "type" : "s", "data" : "low" }here. Dunst does appear to have memory of the urgency, as indicated by the urgency appearance matching the message urgency when usingdunstctl history-pop.I can--and plan to for the moment--to work around this by keeping my own history file with all of the environment variables saved to JSON via dunst-fired script, but it does seem like it's something that should be included in the
dunstctl historyoutput. I could also make the same argument forDUNST_STACK_TAGandDUNST_URLS, though the exclusion of those didn't lead me to create a history workaround and submit this.Installation info
extra/dunstMinimal dunstrc
# This occurs on built-in config