Looped sound

[sullyj3]

Play sound looped while any elapsed timer has a live notification waiting for interaction

closes #106
closes #90

Todo:

• test with different notification servers
• better default sound for looping
  • and include old one
• provide the option of looped or oneshot playback
  needs design work. do we want
  - cli flag?
  - config file?
  - should it be global or per timer?
• cleanup commits

[sullyj3]

the easiest way to handle configuring oneshot vs looped for now is probably to just add an env variable and recommend

systemctl --user edit sand.service

and add

[Service]
Environment = SAND_SOUND=oneshot

[sullyj3]

Actually, I think I'll just change the behaviour to loop and remove the ability to have a oneshot sound. If anyone objects I can add it back in, but there' no reason to complicate things unnecessarily if not

[sullyj3]

Working well with

• swaync
• gnome
• xfce
• cinnamon

It seems like by default dunst automatically closes notifications after a brief period, which cuts the sound short. It's not clear what we can or should do about this from our end. I can't immediately think of any better way of cutting the sound off than tying it to the lifetime of the notification. Especially given that it works well for other notification servers. It's probably a matter of individual user configuration.

fwiw dunst also doesn't seem to support the restart button.

[tuurep]

Hey I can certainly look more into dunst quirks later if that helps

Looking at my scripts, looks like when I've wanted a custom (non-default) time for certain notifiactions, I've used -t flag on notify-send like this:

if [ -n "$fullscreen" ]; then
    notify-send -t 700 \
                --hint=string:x-dunst-stack-tag:volume \
                "$label"
fi

.. or, in a dunstrc field like this:

[NoDistractions_toggle]
    summary = "NoDistractions"
    body = "Enabled|Disabled"

    icon_position = left
    timeout = 1
    history_ignore = true

^ Here I match the notification by the contents of the notif, I believe. Which is a bit of a hack but couldn't figure what else to do.

The latter could be possible for sand I believe?

This man page is going to be the best source of info:

https://man.archlinux.org/man/dunst.5.en

[sullyj3]

Haha yep, I just solved it as you sent that, setting .timeout(Timeout::Never) worked

[tuurep]

Nice sounds good!

Actually, I think I'll just change the behaviour to loop and remove the ability to have a oneshot sound. If anyone objects I can add it back in, but there' no reason to complicate things unnecessarily if not

I do like the oneshot as an idea. Would be nice if for instance a pomodoro user could chime in, that's one case where it may make sense not to need to manually get rid of the notif.

Edit: yeah, I guess I'll go ahead and be the one to request it, the more I think of it, the more useful it is :)

[sullyj3]

righto, good enough for me. Because there's not much to configure yet, I'm a bit reluctant to add the complexity of a config file for now. What do you think about an env variable?

[tuurep]

That sounds just fine to me

Btw Re: dunst and restart action, there's something called a "context menu" that can be opened on a notif, but I have never once tried this. But seems like the best bet, if any.

[sullyj3]

The restart button uses "Actions", which it seems like dunst has support for - skimming the dunst docs there's a thing called do_action

anyway, it seems like middle clicking on the notification does the restart out of the box

mouse_[left/middle/right]_click (values: [none/do_action/close_current/close_all/context/context_all])

Defines action of mouse click. A touch input in Wayland acts as a mouse left click. A list of values, separated by commas, can be specified for multiple actions to be executed in sequence.

Defaults:

    mouse_left_click=close_current

    mouse_middle_click=do_action, remove_current

    mouse_right_click=close_all

I guess since the notification only provides one action, it must be considered the default, so dunst executes it without you having to specify it by name?

[tuurep]

Yeah this is what I know of it:

• when I get a typical chat notif (let's say, discord), clicking on it will focus discord and the correct chat etc.
  • I suppose that's what discord decided is the default action..?
  • annoying but true: if the message times out and I bring it back from history, this action isn't brought with it, now clicking will only close it

A shell command, dunstctl action does the same thing on the most recent notification currently showing on screen. I've bound this to a keybind.

Edit: I didn't know about the middle-click behavior, tried it on a discord message from history, same thing: doesn't do the action, but does the removal part

Edit: yes turns out I have a non-default setting for left click:

    mouse_left_click = do_action, close_current