Yabai: Status Bar On Multiple Display

You would have to create and initialize a status bar window for every connected display, and have it respond to display_removed, display_added events, as well as have all existing code that enables/disables or updates the status bar operate on a collection of status bars instead.

The code to draw the bar itself is already display agnostic. The main change with the exception of what I mentioned above would be to pass in an additional parameter to bar_create function that specifies which display the bar should draw to - instead of it fetching the main display.

I'm not interested in adding this upstream, but feel free to ask questions if you want to try and implement this in your own fork.

@koekeishiya I'd like to help here, could you tell me where I should start?

See my previous comment. The relevant files are src/bar.c, src/event.c and src/message.c. To retrieve a list of current displays, see functions defined in src/display_manager.c

_{Sent with GitHawk}

is this closed because it's addressed or because it won't be addressed?

@benwr

is this closed because it's addressed or because it won't be addressed?

See the 2nd comment in this issue (emphasis mine).

I'm not interested in adding this upstream, but feel free to ask questions if you want to try and implement this in your own fork.

Ah, sorry I didn't read sufficiently carefully.

@shakedlokits, are you working on this feature?

I have an Übersicht configuration at https://github.com/noperator/dotfiles/tree/master/widgets (see spaces.coffee for the feature I'm describing) which shows a status bar on both displays, and levarages yabai -m query --spaces to indicate which spaces are visible on each display. In the attached image:

• Spaces 1, 2, and 3 are assigned to display 1, where space 1 is currently visible.
• Spaces 4 and 5 are assigned to display 2, where space 5 is currently visible.

I've also got this uebersicht widget, which is very similar. Sometimes it seems to crash for unknown reasons though :/

I've also got this uebersicht widget, which is very similar. Sometimes it seems to crash for unknown reasons though :/

That widget is great, thank you!

@noperator The configuration works well. Thanks for sharing.

Note that the widget might cause high CPU usage from yabai, as mentioned here: https://github.com/koekeishiya/yabai/issues/434#issuecomment-595075618. It could be helpful to limit the refresh rate of Übersicht.

Hi @x-ji, thanks for the heads up. That widget is currently configured to refresh every 100 ms just to ensure that it promptly updates whenever I switch between spaces. I saw your comment on the ticket you referenced:

Seems that constantly running the command /usr/local/bin/yabai -m query --spaces is having some performance impact.

Perhaps I'll find another way to update the spaces display that's less CPU intensive. Also, I found @koekeishiya's comment interesting since I've been having issues with mouse clicks not being recognized while using yabai:

Under certain circumstances (heavy load??)…a mouse-click event is not forwarded to the target application if yabai is intercepting it.

Perhaps this high Übersicht refresh rate puts a heavy load on yabai, which prevents it from properly forwarding mouse-click events to the target application. Anyway, just trying to make sense of multiple issues which may be related.

I tried the widget for some time, it doesn't work very well. If I attach to a mirror display then it will break. Sometimes I will need to restart yabai.

I end up using WhichSpace to display the desktop number directly on the mac menu bar.

Because that widget doesn't support secondary monitor, I fork it and create another menu bar item to display secondary monitor desktop number with an alpha. Looks like this:

Here is my forked version.
https://github.com/nuynait/WhichSpace

Perhaps this high Übersicht refresh rate puts a heavy load on yabai, which prevents it from properly forwarding mouse-click events to the target application. Anyway, just trying to make sense of multiple issues which may be related.

It shouldn't really be an issue. The events are processed fine, it's just consuming a higher cpu percentage, as it is doing work more frequent, instead of sleeping.

Perhaps I'll find another way to update the spaces display that's less CPU intensive.

You can use the yabai signal system to have yabai invoke a shell script or applescript (or w/e you want) after processing e.g a space_changed event, instead of having to poll every x ms. I don't exactly know how Übersicht widgets can be targetted, but there is a (not tested by me) sample for it in the yabai wiki in the tips and tricks section.

@nuynait Thanks for the tool 👍 . Though it seems that it currently doesn't work if there are more than 2 monitors? (my third monitor isn't shown on the status bar). I wasn't able to open an issue in your repo.

@nuynait Thanks for the tool 👍 . Though it seems that it currently doesn't work if there are more than 2 monitors? (my third monitor isn't shown on the status bar). I wasn't able to open an issue in your repo.

Now you can open the issue in the repo. I only use a seconday monitor. I can make the change for you if I have time this weekend.

Can confirm increasing that refresh time to 3 seconds makes a significant difference in yabai cpu usage. Dropped from around 4% to alternating between 0.1 and 1.8% during the refresh.

In the last 15 days yabai cpu time was 12 hours. I had never noticed how significant the usage really was. Thanks for sharing the issue.

@nuynait Sure. Opened an issue in your repo.

For those interested—I updated my Übersicht spaces widget to indicate whether a given space has any windows assigned to it or not. In the following example:

• Spaces 2 and 8 are currently visible on the first and second displays, respectively
• Spaces 1, 5, 7, and 8 have windows assigned to them
• Spaces 2, 3, 4, and 6 are empty