Py3status: do_not_disturb module does weird things to dunst

[andaag]

In the standard do not disturb module some weird things are done:

1. Dunst is killed in order to clear notifications - This means applications that check if there is an existing notification daemon - and if there isn't uses their own (such as chrome/telegram) breaks.. They will then default to their own notification system instead of dunst.
2. Kill is used to pause/resume notifications - I've had my dunst daemon completely stop giving notifications when this happens. Instead notify-send DUNST_COMMAND_PAUSE and notify-send DUNST_COMMAND_RESUME can be used.

[ultrabug]

Hi @andaag

Dunst is indeed a bit hard to work with since AFAIR there is no way to check whether it's paused or not on startup...

One side effect of this is that Dunst users (which I'm part of) can for example experience not seeing even py3status startup notifications when starting since the PAUSE / RESUME is used on do not disturb module startup as well and effectively kills any notif...

Would you have other ideas to counter this?

[andaag]

I really don't see a problem with making py3status master of this.

In the 99.9% case py3status and dunst will start at startup, where I believe the only default is that it's resumed. I don't think it's possible to start it paused. So even sending a RESUME on startup - to know the state, and then enable the toggle after that seems sensible for me.

(And I really think the killing of dunst to clear notifications should go away, this breaks other functionality, and it was fairly complex to even figure out what was happening...)

[ultrabug]

The subtlety here lies in the fact that Dunst does queue (and not discard!) notifications while it's paused which if you resume it after a while can be overwhelming and not a wanted behavior...

Check the pause option and the added documentation about this please.

That's why the signal approach was adopted in the first place (which is also valid as per dunst manual).

What do you think?

[andaag]

The subtlety here lies in the fact that Dunst does queue (and not discard!) notifications while it's paused which if you resume it after a while can be overwhelming and not a wanted behavior...

It can also be wanted behavior. So I think it's better to go that route, than to kill dunst in order to provide behavior that might not even be wanted.

Check the pause option and the added documentation about this please.

That's why the signal approach was adopted in the first place (which is also valid as per dunst manual).

What do you think?

Looks like signals are valid, so lets keep those. No need to make a change there. I still think py3status shouldn't be killing it though. (sigterm, not sigusr).

Looks like dunstctl is a valid case to support things like clearing notifications, but that only exists in fairly new dunst versions.

[ultrabug]

dunstctl is indeed interesting and there are two options ahead of us if we want to correctly handle this imho

either we wait until it's released and rely on it to control dunst
or we implement the code logic / tricks it's using into the py3status module

the main learning on reading this bash script is that it shows exactly how to detect if dunst is paused or not and to control it further :)

[andaag]

I did not realize this was a bash script, so yeah, that should make it fairly easy to reproduce in code.

Using NotificationCloseAll also seems to be a valid way to clear all existing notifications.

[ultrabug]

@andaag unfortunately dbus interface has been added in April 2020 and is still unreleased so even if we wanted to mimic dunstctl we would be blocked (I tried...)

https://github.com/dunst-project/dunst/commit/55f4971a929eb939614bd36fa60f2cb3c30f2ba1#diff-adf0911fa112c251da8dbd6cc5fff441

Only thing we can do is wait for the next dunst release I'm afraid

[andaag]

Right, and considering the speed of which packages gets released I doubt we'll see a backport to most distro's.

I still believe the killing of dunst to clear notifications should be removed. That to me is by far the most critical. It's assuming that the user wants a functionality that's not default upstream, and using hacks in order to achieve it.

The perfect setup would be a config flag somewhere that allows picking this, but with it not being possible to do this without killing it - which causes issues elsewhere, I personally think it should be removed..

[ultrabug]

@andaag you can remove this behavior by setting the pause option to True :)

I understand that you think the default to False is not ideal, but you're the first to report it so far tbh

[andaag]

That might be because I needed to use kernel level tracing frameworks to figure out who was sending a sigterm to my dunst process.

During this debugging process I incidentally did find some "why is dunst randomly stopping sending notifications" about dunst itself, on their issue tracker for example. (There's also a bunch of issues around this with the systemctl user integration, where something kills it and it doesn't auto restart).

[ultrabug]

I understand @andaag and I'm sorry you wasted some of your time on this.

I subscribed to dunst github releases and will happily switch the current implementation to a better one once it's possible.

Meanwhile, would you agree to close this issue?

[andaag]

As I said I'd still consider #1 a bug. Instead of going with the default upstream, uses a fairly extreme method (that both breaks other applications where it's extremely hard for a user to understand what's going on), where the prefered behavior is likely up to the user.

I do not consider this a sane default, but if you feel this default is what py3status wants to have then feel free to close.

[ultrabug]

@andaag makes sense ok. I commited the change of the default value.

[ultrabug]

Thanks again for your constructive input mate!

[andaag]

Awesome, thanks a lot 👍

[ultrabug]

@andaag you might be interested to know this: https://github.com/dunst-project/dunst/releases/tag/v1.5.0

unless you already did :)

[ultrabug]

@andaag coming on the next release ;) https://github.com/ultrabug/py3status/commit/e541d756472df04d130cba61e314c307123e1d3d

cheers