-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Customize notification messages #31
Comments
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. |
As Unknown-Zombie says, I'd like to be able to keep just one notification instead of 4 at the time. |
It's unclear to me how to do this... multiple calls to notifyd are displayed in subsequent windows to my knowledge. |
@graysky2 Have a look at this: 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 |
It would be nice to be able to customize the desktop notification priority, too. It seems to me these notifications should be |
@Xiaoming94 - In playing around with the script, I am unsure what is functionally different between a low and normal urgency setting. |
@graysky2, the specification doesn't clarify the distinction between http://www.galago-project.org/specs/notification/0.9/x320.html
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 |
@graysky2 wrote:
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 The big hangup with the
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. |
Great tool and great proposals here! My use case is extremely simple: 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! ;-) |
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)
The text was updated successfully, but these errors were encountered: