Inconsistent title cycle duration

[cwernert]

Describe the bug
When more than one title is output to the header:

• Previously: SwiftBar cycles through displaying the titles one at a time for 5 seconds each
• On v1.4.4: The first title seems to dominate, with subsequent titles appearing briefly and intermittently. Eg. first title might be shown for 12 seconds, then second title is flashed for <1 second before first title is displayed again, this time for a different duration.

To Reproduce
Steps to reproduce the behavior:

1. Create a plugin which outputs at least 2 titles to the header ( before the first ---)
2. Enable the plugin and monitor the display duration for each title

Expected behavior

• Each title should be displayed for a standard duration (eg. 5s)
• Titles should cycle on a loop, giving equal display time to each

Screenshots
https://cdn.zappy.app/va6dcd69c28fedf440a101c61a04693f9.mp4
See 00:27, Menu Item 2 flashes at ~00:28

Environment:

• macOS version: 12.5.1 (also observed on 13.0)
• SwiftBar version: 1.4.4 (see note in Additional Context)
• node version: 16.8.0 (also observed on 12.22.3)

Plugin Example:

#!/usr/bin/env node
console.log("Menu Title 1");
console.log("Menu Title 2");
console.log("---");
console.log("Body content");

Additional Context:

• I don't run Bartender/Dozer/etc. or tested the issue without it running (observed both with & without Bartender)
• This was reported to me by a colleague running v1.4.4 and I couldn't reproduce it on the older version I was running (sorry, I'm not sure which). While comparing environment versions between our machines, I noticed my SwiftBar was outdated. Once I updated to v1.4.4, I saw the issue.

[melonamin]

Hey @cwernert, awesome bug report, thank you.

It is indeed a bug introduced in 1.4.4, here is what happens: SwiftBar cycles through titles every 5 seconds and plugin updates every 10 seconds, they overlap and as soon as the menu bar switches to Title 2 SwiftBar updates the plugin and menu bar goes back to Title 1.

This didn't happen before 1.4.4 because SwiftBar would NOT refresh the menu bar if plugin output didn't change since the last time.

I changed this behaviour when implementing #321, let me look into it

[cwernert]

Hey @melonamin - thanks for such a quick analysis, and even moreso for this seriously awesome tool! We certainly love the new "Dim on manual refresh" feature; so it's worth ironing out a few minor kinks.

That totally makes sense - and it seems like a quick workaround for the meantime would be adjusting the frequency of the plugin. As long as "frequency > 5 * # of titles + 5" we get to see each one sufficiently :)

I wonder whether it's possible to get the best of both worlds, ie. when a user manually clicks "refresh" we force a menu bar update regardless of whether the content has changed - otherwise don't refresh the menu bar if the output hasn't changed. Is that technically feasible?

Alternatively (this might be a huge lift so feel free to disregard), would it help if:

• The desired title presentation duration could be set in the plugin preferences
• SwiftBar could count the number of titles in the header, and set the refresh frequency dynamically
• Dynamic refresh can also be enabled/disabled in the plugin preferences

For example, if a plugin declares <swiftbar.titleDuration>5s</swiftbar.titleDuration> and then outputs 3 titles, SwiftBar would know not to refresh that plugin again for 15s to ensure each title is displayed and the refresh moment happens when we'd expect to see the first title again, effectively "hiding the seam".

That may or may not be a terrible idea, but I'll keep brainstorming to see if I can come up with a creative suggestion :)

[melonamin]

Heu @cwernert, do you mind trying this beta build? It should address this issue

[cwernert]

Looks brilliant @melonamin; love your work!
I tested with a few different update frequencies - even really short ones like 2 seconds - and never saw the issue.
I believe this build resolves this issue; thanks so much for such a fast turnaround here :D

[RasHanz]

Thank you @melonamin! I also tested it, and the issue appears to be fixed, indeed. I appreciate your work!