Different behaviors when run from command line or through homebrew

[bustinbung]

I recently started having this issue with my current setup. When I run sketchybar via homebrew (brew services start sketchybar), I get buggy colors and unexpected output from my plugins. When I run sketchybar via the command line, the behavior goes away. I've attached a screen recording that hopefully demonstrates this.

Notice:

• Multiple spaces "active" at a time
• Wrong space highlighted (space 3 (browser) highlighted when space 2 (emacs) is open)
• Colors inverted

I wasn't thinking about submitting an issue, but given that it only occurs when run through homebrew, I wonder if it isn't the fault of my (poorly written) plugin. Thanks for the help!

EDIT: I just made my dotfiles repository public. If you need to look at what I have running, you can look at it here

Flashing screen warning

Screen recording

https://github.com/FelixKratz/SketchyBar/assets/22670587/d4cb849a-ccf1-42c2-ad13-c8cb09faf194

[FelixKratz]

Could you check what is written to the log files located in /opt/homebrew/var/log/sketchybar? These contain the output of sketchybar when it is run as a brew service.

Apart from that I think it would be best to separate the space highlighting logic from the windows on spaces logic, as you likely create a lot of overhead by executing all of the logic in all of the spaces on all of the events and this will be prone to race conditions. So maybe a separate item that exclusively handles:

space_windows_change
space_created
space_destroyed

(IIRC the space_change event and space_windows_change event ist executed automatically if a space is created/destroyed on macOS 13+) for reference: https://github.com/FelixKratz/dotfiles/blob/master/.config/sketchybar/plugins/space_windows.sh

[bustinbung]

Only thing I see in the logs is sketchybar: could not acquire lock-file... already running?. I'll see if I can move the logic out of the spaces plugin, but it'll probably be a second before I can get to it. Thanks for the tip!

Should I continue to keep this issue open? It might just be an overhead thing like you mentioned.

[bustinbung]

I went ahead and moved the logic for space labels and space selections to their own functions and that seemed to have solved the issue (see 186ada3). I've still got some bugs to work out, but I'm going to go ahead and close this issue for now.

[FelixKratz]

I am certain that it is a race condition between the space_windows_change event and the space_change event. It is because both events are emitted on a space change, and depending on wether the internal state of the SELECTED variable was set before or after the space_windows_change event is executed you can have the following scenario:

1) You request a space change 2) The space_windows_change event is emitted with the $SELECTED variable being in the "old" state 3) The space_change event is emitted with the new $SELECTED variables set 4) The scripts are executed asynchronously, which means it is essentially random which event goes through the logic which sets the color based on the SELECTED property last 5) If the space_change is handled first and only afterwards the space_windows_change event is handled in the script, you get the wrong highlighting.

All of this is avoid by separating the logic for these two events.

[bustinbung]

Thanks for clarifying, really appreciate your work in creating this for the community!