Customize notification messages

[RobertAudi]

It seems like the notification messages text are hardcoded in the script. It would be nice to be able to customize them (e.g.: via the config file)

[Unknown-Zombie]

I would like this too. More specifically, I'd like to have it so the program only shows 1 notification at a time so that my screen doesn't fill with notifications when rapidly increasing or decreasing the volume.

[marsicplusplus]

As Unknown-Zombie says, I'd like to be able to keep just one notification instead of 4 at the time.

[graysky2]

would like this too. More specifically, I'd like to have it so the program only shows 1 notification at a time so that my screen doesn't fill with notifications when rapidly increasing or decreasing the volume.

It's unclear to me how to do this... multiple calls to notifyd are displayed in subsequent windows to my knowledge.

[Xiaoming94]

@graysky2 Have a look at this:
https://github.com/vlevit/notify-send.sh

Maybe use some code from here, alternatively, use this as an optional dependency in your script :)

EDIT: I can work on this and submit a pull request if you wish

[nmschulte]

It would be nice to be able to customize the desktop notification priority, too. It seems to me these notifications should be urgency_low out of the box, given the notification is likely to be a direct feedback to an action from the user.

[graysky2]

@Xiaoming94 - In playing around with the script, I am unsure what is functionally different between a low and normal urgency setting.

[nmschulte]

@graysky2, the specification doesn't clarify the distinction between urgency: low and urgency: normal, other than hinting that they may have different timeouts.

http://www.galago-project.org/specs/notification/0.9/x320.html

Notifications have an urgency level associated with them. This defines the importance of the notification. For example, "Joe Bob signed on" would be a low urgency. "You have new mail" or "A USB device was unplugged" would be a normal urgency. "Your computer is on fire" would be a critical urgency.

Developers must use their own judgement when deciding the urgency of a notification. Typically, if the majority of programs are using the same level for a specific type of urgency, other applications should follow them.

For low and normal urgencies, server implementations may display the notifications how they choose. They should, however, have a sane expiration timeout dependent on the urgency level.

Critical notifications should not automatically expire, as they are things that the user will most likely want to know about. They should only be closed when the user dismisses them, for example, by clicking on the notification.

This is why I propose making the urgency level configurable (between low and normal, at least; I can imagine an scenario where it may be useful to notify with critical urgency, but that's an atypical use-case).

I use Dunst as my notification daemon, and it allows me to fully configure how notifications are presented; it also lets me override attributes based upon an attribute matching scheme. This override ability will let me change pulseaudio-ctl's notification urgency, but not all notification daemons allow this much control.

(from https://dunst-project.org/screenshots/)

[nmschulte]

@graysky2 wrote:

It's unclear to me how to do this... multiple calls to notifyd are displayed in subsequent windows to my knowledge.

To this end, Dunst allows to configure how similar/identical/same-app-initiated notifications stack. I don't think all daemons allow this.

I didn't believe that the desktop notification protocol allowed post-facto control over the notifications, and instead that they were "fire and forget" (no control after creation). That notify-send.sh implies otherwise, which is neat to see.

---

The big hangup with the notify-send.sh script is that it requires remembering the ID of the message you want to modify/replace. pulseaudio-ctl is not resident in memory; the application exits after changing the volume and sending the notification. pulseaudio-ctl would need to change how it works in order to allow this. It could:

1. stay resident in memory and exit; like a daemon
2. persist the last/recent ID somehow

It's not entirely clear how multi-user environments affect this picture, though this isn't a new concern. PulseAudio and D-Bus / the notification daemon already take a stance on dealing with the "audio is a shared resource" issue.

It's likely not worth the effort, given that this issue is something that the notification daemons have to deal with in general already.

[nsk7even]

Great tool and great proposals here!
I would love to be able to customize the notifications as well.

My use case is extremely simple:
Print the current (effective) volume in the text line with bigger and bold text and the action (up/down by 5%) in the text line with the smaller text.

Because: it was me that initiated this action, therefore I (mostly) know what I've done - it is more interesting to me to what volume level my action resulted! ;-)