Support for multiple instances of Waybar to exclude multiple notifications

[AlxTray]

I'm not too sure if there is a way of fixing this but currently a desktop notification is sent per waybar update, so with 2 monitors, 2 sets of notifications are sent.

[savely-krasovsky]

@jlaunay do you have this problem?

[jlaunay]

No, I have two monitors, and whether it's on Sway or Hyprland, notifications never appear twice. EDIT: but waybar-updates is only on the main bar, not on the one for the second monitor.

[savely-krasovsky]

Same here, @AlxTray do you use the latest version? Also could you maybe add some details? waybar-updates send multiple notifications if there are updates from various sources: Arch official repos, AUR, devel-packages (which should be synced with their master/main branch).

[AlxTray]

Hey, thanks for replying. I'm on the non-git package from the AUR, and sources are just pacman and AUR, no devel.

I do have the module on both waybars, so it seems that it probably is just a waybar thing, with it making multiple processes.

[savely-krasovsky]

AFAIK yes, waybar still has a bug when it leaves orphan processes after own restart. Killing process manually should probably help. Please confirm after testing.

[AlxTray]

Hey, yeah I am able to kill the processes manually. But I am also getting this upon startup.

Though moving forward I’m going to just have the module on my primary monitor as either way this seems like a consequence of waybar itself, as weirdly enough if I’m to create a module that just executes “checkupdates | wc -l” on both waybars, only 1 waybar actually gets the line count.

[savely-krasovsky]

Oh, I got it. Waybar starts waybar-updates on every own instance and it cause multiple notification. Well, this is potentially could be fixed by introducing some user background service (launched systemd for example) and making sure that it could have only one client per time, not multiple.

Unfortunately this will be a major overhaul and should be better entirely rewritten to something better suited than Bash (Go, Python, or at least nushell?).

I will keep it open, maybe at somepoint I will have some time to do it.

[jlaunay]

...or adding a command line option to disable notifications, on first bar exec as usual and on the second exec with notifications disabled.

[savely-krasovsky]

Well, yes, but in that case waybar-updates will still do useless work (by quering AUR helper API and crashing at Arch official repos asking for updates), in my opinion it's bad to waste community resources while we could offer a better solution.

[AlxTray]

Yeah, sounds good. It could be a nice addition to just have an argument that just disables notifications outright though.

Thanks for taking your time to help

[savely-krasovsky]

I would use it only as a temporary workaround, you could easily apply it by hand. By upstreaming this change no one will know it's even a problem, unless they will read code for some reason. Hope you understand my point!

[jlaunay]

Well, yes, but in that case waybar-updates will still do useless work (by quering AUR helper API and crashing at Arch official repos asking for updates), in my opinion it's bad to waste community resources while we could offer a better solution.

Completely agree, I hadn't thought about that at all and just focused on the issue of not generating a second notification. Several solutions are possible, but for now, the best option is to use 'waybar-updates' only on one bar.

[savely-krasovsky]

Simple approach: create a background service from the current script, but instead of posting json updates to stdout, post them to temporary file (by replacing content, not appending). Write a new "client" script which will just read this file and post it to own stdout from which Waybar will get new statuses. Notifications will be still handled by current script, but it will has only one instance in that case.

[AlxTray]

I was actually just thinking of making a quick hacky solution of creating a service, having it print to stdout and then reading from journalctl on the waybar side. But that is a lot better lol

[savely-krasovsky]

You idea is also nice, but I don't think running 2-3 instances of journalctl is a good idea in a long term.

[AlxTray]

Yeah, definitely would not be a good permanent solution

[savely-krasovsky]

I am personally don't have a lot of time right now, also I am currently using laptop with GNOME cause I moved to another country recently. If you want, you could try to prepare MR, @AlxTray. In my opinion it should not be hard.

[savely-krasovsky]

For notifications to work it should be a user service, otherwise it will unable to connect session d-bus I guess.

[AlxTray]

Yeah, I don’t mind giving it a go at some point, probably will have to be over the weekend though

[jlaunay]

I'm not sure if this will be ok for you, but I tried to implement a quick and hacky solution and it seems to be functional. In the waybar configuration, for the second instance, I launch it with waybar-updates -s. You can see the modifications here and here (instances branch).

[AlxTray]

Yeah, that's a good-enough solution for now. Thanks for setting that up

[switch-blade-stuff]

A possible solution would be to start a systemd user service that broadcasts output of waybar-updates as a signal on the D-Bus session bus and then listen for the signal from a waybar client module. This way we only have one process checking updates and sending notifications regardless of how many waybar instances are running.

I am not an expert in bash, but I think this can be accomplished via dbus-send and dbus-monitor like so:

# Server-side
dbus-send --session --type=signal / com.example.waybar_updates.notify_client string:"<content>"

# Client-side
dbus-monitor "interface='com.example.waybar_updates',member='notify_client'"

The client would then need to grep the output of dbus-monitor for the com.example.waybar_updates interface and notify_client member before extracting the string message, since dbus-monitor also monitors the org.freedesktop.DBus interface signals to my knowledge.