Graphical Issues & Island Unresponciveness
Closed this issue · 11 comments
I pulled the latest commit and sadly the bar is now completely unresponsive.
Screen.Recording.2022-10-03.at.23.16.14.mov
running sketchybarc:
/Users/name/.config/sketchybar/items/dynamic_island.sh: line 5: /Users/name/.config/sketchybar/plugins/dynamic_island/data/active: No such file or directory
Ahh, it seems like the "data" folder is missing. I've added data folder in .gitignore, as it included my personal notification data etc.
The cache files can be generated on their own, it's just that data folders have to be made manually. I'll make a commit that fixes this shortly.
running touch on those files causes the bar to respond but still with graphical problems and severe lag (with notifs disabled) there is constant displaying of the now playing song like it is being polled every few seconds. Titles mismatching is now an issue same with album art.
Screen.Recording.2022-10-03.at.23.34.12.mov
I'm not really able to reproduce the severe lag problem. From the looks like it, it seems like more than one feature is trying to access the dynamic island at the same time (which it shouldn't happen after I "fixed" earlier today; but the corners of dynamic islands seem to be constantly changing).
It's also quite odd how the previous commit (before the breaking change) didn't cause as much graphical issues as after the commit.
Essentially, each feature should prevent the dynamic island to change for a set duration while it's being active (which is checked via a "active" file in data/active). Except for the feature of same type (e.g. dynamic island currently drawing "music", it can be instantly replaced if music island gets activated). This request can take over dynamic island instantly. This might be the problem.
Could you also try disabling volume feature (also by commenting out in ~/.config/sketchybar/plugins/dynamic_island.sh)? This feature comes disabled by default with the new commit, but just in case. Volume module is the only module that is not currently supported by this "only one island at a time" feature.
I will be doing more investigations tomorrow (it's getting late here).
Much fewer issues and app switching now works. There is less lag but still graphical glitches.
Screen.Recording.2022-10-04.at.00.15.37.mov
I will be able to help tomorrow more it's currently 00:17 for me so yeah. I will send more updates and ill look around fixing files.
if you could add me on discord it would make sending issues much faster: 112c#7777
I edited my config to allow notifications, I had set it up correctly but it wouldn't run. So I read the python file and needed to run:
pip3 install biplist
Screen.Recording.2022-10-04.at.11.49.30.mov
So I read the python file and needed to run: pip3 install biplist
This is something I realised yesterday after the initial release, so I've made changes to the requirement section in README.md.
As for the graphical glitches that is still occurring, something odd is that the dynamic island opens up far slower on your end. Might be a long shot, but could you try setting the update_freq to something bigger like 5 in ~/.config/sketchybar/items/dynamic_island.sh (line 26)? Remember to restart the SketchyBar to take effect (brew services restart sketchybar).
There also seem to be parsing errors when handling notifications (and notification island in general), I'll need to look into that problem as well.
I set it to 5 at first still glitching and a bit slow, and then changed it to 15. I have also realised its truncation of song names are inacurate.
With Update Frequencey 15:
Screen.Recording.2022-10-04.at.19.32.11.mov
Update Frequencey 5:
Screen.Recording.2022-10-04.at.19.27.12.mov
Hmm. It's weird how the island does not glitch at all when it's showing "Resumed" (and runs at intended speed). I was going to suggest retrieving album artwork might be a potential issue, but if that's the case, it shouldn't glitch the dynamic island when it's closing.
Is this issue still present? Ever since the integration of the new helper program, the graphical unresponsiveness issue no longer seems to be as big of an issue.
closing due to inactivity