Notification management outside of dunst

[tkna91]

Hi! I am using mako as my notification server on sway. And if possible I would like to do notification control etc. I imagine this is a problem that occurs in all environments except dunst. What should I do?

Screencast:

https://github.com/kantord/i3-gnome-pomodoro/assets/102382754/aed1b916-868a-44c4-9f19-6f4a861584da

[tkna91]

I think the problem is that currently, if you do something like i3-gnome-pomodoro daemon 1 2 3 4 5 6 7 8 9 10 to specify a workspace that cannot be focused, it forces the desktop notification stop function by dunst to work unconditionally. I feel that it would be better to first isolate that functionality as a command line option (such as --no-notify).

[kantord]

Yeah, it's a good idea to introduce a (--no-notify) flag for this, PR welcome for that.

Regarding the dunst functionality, probably the solution is to refactor it to use dunstctl and do nothing if dunstctl is not present in the system. While this will not support pausing the notification in another daemon, you will at least not see those dunst command notifications.

Then it would be another thing to do something like supporting pausing notifications in mako. I guess that would be handled with https://man.archlinux.org/man/makoctl.1.en

I guess the bigger question is how to handle selecting the correct notification system. I have 2 options in mind:

• do it like i3-sensible-terminal which basically has a list of terminals and the first one to exists in PATH is being used
• allow the user to use a configuration file to configure this feature

Probably the first option could be implemented first? That will work out of the box unless you have both dunst and mako installed.

PRs welcome for all of this functionality

[tkna91]

• allow the user to use a configuration file to configure this feature

Unfortunately I am not yet competent enough to write a PR, but after a little research it looks like a good way to do it. It seems that mako does not allow users to manage the hiding/stocking of notifications unless they configure it voluntarily, as shown below.

$ tail -n 2 ~/.config/mako/config
[mode=invisible]
invisible=1
$ 
$ notify-send "$(date)"       #notified
$ makoctl mode -s invisible   #set mode
$ notify-send "$(date)"       #not notified
$ makoctl mode -r invisible   #notifications are restored
$ 

Screencast:

https://github.com/kantord/i3-gnome-pomodoro/assets/102382754/20da944f-629e-471e-96b5-f00964e479a1

[kantord]

ok, so what I understand is that i3-gnome-pomodoro cannot just assume that your mako has a certain mode. I think that it means that it would not be practical for i3-gnome-pomodoro to offer a mako-specific feature and instead it would make sense to offer the ability to run a custom script, in which you could run makoctl commands as you see fit. Also, you could look into whether there is already an app that can do that. Basically i3-gnome-pomodoro is using dbus to talk with gnome pomodoro. Maybe there is some app that can already achieve this using dbus with some manual configuration