[Question] Single module execution on multiple monitors

[apiraino]

As a test, I wrote a custom module that just prints a semi-random number:

    "custom/counter": {
        "exec": "bash -c 'echo $RANDOM'"
    },

Then I start Waybar (under Sway) with waybar -b bar-0.

When I have two monitors connected, Waybar shows 2 different numbers on the monitors. I expected to see the same number on both monitors.

I'm probably missing how Waybar works: although I see many child processes, I thought Waybar runs as a single process and each module is executed just once.

Can anyone help me understand that? Is there a way to run a module exactly once per Waybar instance?

thanks

[Carltoffel]

I have the same problem. A workaround would be to have a separate script for generating the desired output into a file. Then you can read that output from the file in your exec statement. I wish this would be easier. An option to run only one instance and mirror the values for each waybar would be really appreciated.

[samgriesemer]

I also encountered this when trying to set up something like the custom pacman module in the wiki. I have the same waybar displayed across 4 monitors, but after every waybar refresh, only 2 monitors were showing tooltip text when hovering over the module. After some digging it appeared waybar was actually invoking my script 4 separate times (once per monitor), and checkupdates appears to error out when being called in rapid succession. Only a few monitors were catching successful results to display.

This seems like a pretty poor model for modules that are expected to always show the same data across outputs. Event-driven interaction is pretty clunky as well: a click event that changes module data by default applies only to a single monitor, unless the result is stored and a signal is sent to tell the waybars on other monitors that something has changed. Of course, some modules need data specific to the output on which they're drawn. But I agree with @Carltoffel, it'd be great if custom modules could be tied to a particular context (something like a "scope" parameter that could either be set to "output" for execution local to each monitor, or "session" to tie results from exec calls to the global waybar session).

[mkavanagh-23]

I also encountered this when trying to set up something like the custom pacman module in the wiki. I have the same waybar displayed across 4 monitors, but after every waybar refresh, only 2 monitors were showing tooltip text when hovering over the module. After some digging it appeared waybar was actually invoking my script 4 separate times (once per monitor), and checkupdates appears to error out when being called in rapid succession. Only a few monitors were catching successful results to display.

This seems like a pretty poor model for modules that are expected to always show the same data across outputs. Event-driven interaction is pretty clunky as well: a click event that changes module data by default applies only to a single monitor, unless the result is stored and a signal is sent to tell the waybars on other monitors that something has changed. Of course, some modules need data specific to the output on which they're drawn. But I agree with @Carltoffel, it'd be great if custom modules could be tied to a particular context (something like a "scope" parameter that could either be set to "output" for execution local to each monitor, or "session" to tie results from exec calls to the global waybar session).

I definitely agree with this sentiment. Decided to write my own updates module myself and ran into the same issue. Spent quite a bit of time building out a caching and validation system to prevent race conditions and ensure proper output on all monitors... still likely have some edge cases that don't work. A flag to set the scope or environment for global script execution would be very nice and much more intuitive

[isak102]

I also encountered this when trying to set up something like the custom pacman module in the wiki. I have the same waybar displayed across 4 monitors, but after every waybar refresh, only 2 monitors were showing tooltip text when hovering over the module. After some digging it appeared waybar was actually invoking my script 4 separate times (once per monitor), and checkupdates appears to error out when being called in rapid succession. Only a few monitors were catching successful results to display.

This seems like a pretty poor model for modules that are expected to always show the same data across outputs. Event-driven interaction is pretty clunky as well: a click event that changes module data by default applies only to a single monitor, unless the result is stored and a signal is sent to tell the waybars on other monitors that something has changed. Of course, some modules need data specific to the output on which they're drawn. But I agree with @Carltoffel, it'd be great if custom modules could be tied to a particular context (something like a "scope" parameter that could either be set to "output" for execution local to each monitor, or "session" to tie results from exec calls to the global waybar session).

Ran into the same issue with checkupdates, solved it by just letting it retry with a delay up to 5 times until it got an exit code of 0 (ugly fix). But I definitely agree that this should at least be an option in Waybar and I was surprised when I found out it wasn't the default behaviour

[apiraino]

@Alexays any thoughts on this? You probably have a good context about the codebase - how feasable would it be to change Waybar to have a single process for multiple outputs?

thanks

[haug1]

It's something I've loved to work on for a while, but never found the time. After getting my hands on latest Claude Code model and doing an experiment I've decided to take this on in a "casual fashion", I probably won't chase this further, but I've done this completely AI-driven PR on this issue: #4563
Have a look if you're interested.