Closed imsamuka closed 2 years ago
# run this program, display the output notify_sumary = mpc current -f [%title%]|[%file%] notify_body = mpc current -f [by %artist%]
I really don't see the benefit of invoking mpc current
, as mpDris2 already has all necessary metadata and could just format the string internally. And even more so, getting the metadata from arbitrary commands via sh -c
feels like it practically defeats the point of mpDris2.
# pass all music tags through hints notify_tag_hints = True
notify_paused
is specially useful, and probably very easy to implement.notify_timeout
can be ignored, but it is good to have.notify_tag_hints
are useful for tinkerers: using a powerful notification server, you could change the notification look, based on a music genre, for example. It can be ignored too.
Sending structured notification metadata as hints sounds interesting, but I don't think I've seen notification servers have that sort of configurability. Is there a working prototype, or is this currently just an idea?
(And if the notification server is configurable to that extent, couldn't it also override the timeout based on the sending app, and/or hide notifications with "Paused" as the title, making the other two options redundant?)
mpDris2 already has all necessary metadata and could just format the string internally
I see. I was going to suggest the internal string formatting but thought it was a bit hard to implement. But also, I think it's a good idea to use the same syntax of mpc
as it would be already well documented and increases consistency.
Is there a working prototype, or is this currently just an idea?
It was just an idea of mine, although i can imagine someone doing this with things like tiramisu. I don't know any graphical notification servers that can be customized to that extent yet, though.
(And if the notification server is configurable to that extent, couldn't it also override the timeout based on the sending app, and/or hide notifications with "Paused" as the title, making the other two options redundant?)
Of course. If someone is using such a notification server, that is not a problem. But many servers don't have that kind of configuration
In my case i worked around it on dunst config:
[mpd]
appname = Music Player Daemon
timeout = 5
[mpd_ignore_paused]
appname = Music Player Daemon
body = "*(Paused)"
skip_display = yes
But it feels a little dirty, if I will delete the "(Paused)" notification anyway, it's better to never send it in the first place.
About the timeout, well, assuming even notify_sumary
(and others) are implemented, it seems sensible to include a timeout option too, i guess?
I am strongly for the idea of formatting the notification summary/body using the internal string formatting mpc uses. @grawity , if this sounds good to you, I will try to implement this (its literally the only feature stopping me from switching to mpd/mpDris2) and send a PR.
I couldn't help myself... I went ahead with a PR. @imsamuka if you want to test it out I'd be greatly appreciative.
Since #136 implemented most of what was proposed, i will close this.
You meant #156
Notification Text
Even better, run in a
sh -c
wrapper.About the notifications that show up when the music is paused, it can be 2 extra options
notify_paused_sumary
andnotify_paused_body
.Notification Options
notify_paused
is specially useful, and probably very easy to implement.notify_timeout
can be ignored, but it is good to have.notify_tag_hints
are useful for tinkerers: using a powerful notification server, you could change the notification look, based on a music genre, for example. It can be ignored too.