-
-
Notifications
You must be signed in to change notification settings - Fork 108
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
On wake from sleep, bar is not visible, hacky fix. #497
Comments
Interestingly, this kind of bug has been around for quite some time now and I am not entirely sure what could be the reason for this (#430, #422). I have not been able to reproduce this problem but I think it has something to do with external displays, can you confirm that this is only a problem on external displays? Could you share some more system information and importantly test if this kind of bug also happens with this kind of minimal config: sketchybar --bar color=0xffffffff height=40 Thanks for testing! |
I suspect this will be monitor related, I have two external monitors, one Benq and one Dell / Alienware. I have had issues with this setup on a different machine with both these monitors running Hyprland on arch. I assumed this was maybe Hyprland related. That said no issues on MacOS (unmodified) / Windows. I will do some testing for you and report back. |
OK I can make it break with just a simple bar config, as follows. #!/bin/bash It gives no error / debug messages when running in foreground. Further funky complicated hardware info Mac Mini M1 |
Do you need to enter a password to unlock the screen after sleep or no? I could imagine that this might be a timing problem, where we are handling the system_woke event before the displays are connected but the system does not send another display connect event. This leaves us in a state where sketchybar does not know about the displays and thus does not draw a bar. |
Yes I do need to enter a password to unlock. So it will wake the Mac and the monitors then ask for a password. It could well be a timing issue. I am working around by using an app that allows me to run a script on wake but maybe that is doing different timing. |
What would be interesting to see is whether the To test this you can run the following: sketchybar --add item woke left --set woke label="No" script='sketchybar --set $NAME label="$SENDER"' --subscribe woke system_woke There should be an item appearing in your bar which should say |
I can confirm with that test config I am getting system_woke messages on the bar. So it is receiving the system_woke message. This is waking from a full sleep where I have to enter my password. |
What happens if you perform your hacky workaround of changing the display property inside of this script? I.e.: sketchybar --add item woke left --set woke label="Testing" script='sketchybar --bar display=main display=all' --subscribe woke system_woke without any other script doing the same thing? If this works it confirms that it is a timing issue. |
I did do a test of this and it did indeed work. I then went to do some further testing to make the bar break again and then swap between configs to A / B test and now I can't make the bar break! I have now got my hack work around disabled and every time I put it into sleep and it comes back the bar work (this is without your config to change the display property). I am confused, I am going to run this for another week and see if I can break it again and report back, if I can't I can close this off as, well I don't know! |
Have tested on 2.16.9 and 2.20.0.
When my mac (Sonoma 14.3 Mac M1 Mini) goes to sleep and then wakes sketchybar is running (tested by running foreground in terminal) but not visible.
sketchybar --bar hidden=off does not work neither does toggling on and then off.
However if I run sketchybar --bar display=main the display=all it works.
Odd behaviour and I can work around it with a wake script with sleepwatcher but thought it was worth raising a bug. Happy to test etc, if it makes any difference I am running yabai WM
The text was updated successfully, but these errors were encountered: