dunst-project / dunst

Lightweight and customizable notification daemon
https://dunst-project.org
Other
4.42k stars 338 forks source link

Dunstify with hint -h int:value:$VALUE is not printing #1310

Closed sonalys closed 3 months ago

sonalys commented 3 months ago

Issue description

I don't receive any notification when using -h int:value:{0 to 100}

Example command:

dunstify \
        -h string:bgcolor:"#343434" \
        -h string:hlcolor:"#e44138" \
        --urgency=critical \
        -r 2593 \
        -h int:value:50 \
        -h string:x-canonical-private-synchronous:volume \
        "Volume"

I tried downgrading until 1.9.1, and it still doesn't work.

Installation info

Minimal dunstrc It won't run in with any dunstrc, even without one.
zappolowski commented 3 months ago

I can't reproduce the issue here.

Could you please run dunst with -verbosity debug, issue your command and post the output here.

sonalys commented 3 months ago

My bad, I double-checked, and I had /usr/share/dbus-1/services/org.freedesktop.Notifications.service set to notify-osd Some update probably broke it, I set back to dunst, and it's working.

It's just weird that dunstify is not using dunst, but the default notification service

zappolowski commented 3 months ago

It's just weird that dunstify is not using dunst, but the default notification service

That's not weird, but working as intended. There can be one and only one notification daemon running at a time ... notify-send and dunstify as well don't communicate with a notification service directly but with a DBus interface (that's where the restriction of a single service comes from).

sonalys commented 3 months ago

I know. I just assumed dunstify would alert me that dunst is not running by default or something.

It would be pretty nice.

zappolowski commented 3 months ago

dunstify --serverinfo already provides information about the running server (so, you could already check it before sending your notification).

I'm not sure whether it is really beneficial to add a new check for a "compatible" (whatever this means in this context) notification server before sending any notification ... especially doing this by default. This use case seems to be rather niche.