Skip to content
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

Notification management outside of dunst #48

Open
tkna91 opened this issue Feb 29, 2024 · 4 comments
Open

Notification management outside of dunst #48

tkna91 opened this issue Feb 29, 2024 · 4 comments

Comments

@tkna91
Copy link

tkna91 commented Feb 29, 2024

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:

20240229-204811_screencast.mp4
@tkna91
Copy link
Author

tkna91 commented Mar 3, 2024

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
Copy link
Owner

kantord commented Mar 4, 2024

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
Copy link
Author

tkna91 commented Mar 6, 2024

  • 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:

20240306-200611_screencast.mp4

@kantord
Copy link
Owner

kantord commented Mar 6, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants