Also experiencing this catching up bug after my computer wakes up from sleeping. And glazewm provider not working after waking up from sleeping, requiring zebar to be refreshed to receive workspace updates from glazewm. I am using glazewm v3.0.0 and Zebar 1.7.0. Perhaps zebar needs to automatically be refreshed after waking up from sleep, or just the code for the glazewm provider.

I have the same experience still.

The Komorebi provider also "freezes" everything, but with the recent changes it seems less frequent.
I also noticed this freezing issue without letting my computer to go to sleep. After some time, the bar stops updating and when I click the bar and then click a window it does this "catching up".

I am assuming that there must be something about the code that handles updating the bar for both the Komorebi and Glazevm providers. When I don't use the Komorebi provider the bar is much more stable.

@lars-berger Would there be a way I can help tracking down this issue? (I will try to capture this again when it happens without the computer going to sleep)

I use this for Komorebi (seems to work better with 2 monitors)

    template/komorebi:
      providers: ['komorebi']
      template: |
        <div class="template-block">
            @for (monitor of komorebi.allMonitors) {
              @if (self.args.MONITOR_NAME.endsWith(monitor.name)) {
                <div title="Self: {{self.args.MONITOR_NAME}} | {{monitor.name}}({{monitor.focusedWorkspaceIndex}})">
                  @for (workspace of monitor.workspaces) {<div title="{{workspace.layout}}" class="workspace {{monitor.workspaces.indexOf(workspace) === monitor.focusedWorkspaceIndex && 'active'}}">
                      {{workspace.name || "&nbsp;"}}
                    </div>}
                </div>
              }
            }
        </div>

@lars-berger I managed to catch this behaviour without putting the computer to sleep.

It was stuck for a while before I started recording, but once I started, it ran the UI updates rapidly (by default it should update every 2 seconds).
I switched between clicking the bar and the Firefox window and the UI updates get stuck sometimes. This only seem to happen when I use the Komorebi provider.

Just to be clear, when I don't use the Komorebi provider, then this "catching-up" happens after waking from sleep, but it does not get stuck in the middle. When I use the Komorebi provider then this happens even without sleep.

Could this be related to when Komorebi pushes an update in the socket connection, the UI thread in Zebar gets stuck?

Komorebi made the interface public, so I was wondering if using that instead of the socket connection can fix this issue, but this could very well be a thread locking issue?

@lars-berger I ran Zebar locally to see the logs and try to reproduce the issue. I use the Komorebi provider and when the bar gets stuck I see the following error after the bar starts catching up (as seen in the video previously)

packages/desktop dev: 2024-08-06T08:19:47.704072Z  WARN tao::platform_impl::platform::event_loop::runner: NewEvents emitted without explicit RedrawEventsCleared
packages/desktop dev: 2024-08-06T08:19:47.709268Z  WARN tao::platform_impl::platform::event_loop::runner: RedrawEventsCleared emitted without explicit MainEventsCleared

Komorebi provider:

    template/komorebi-focused-window:
      providers: ['komorebi']
      template: |
        <div style="background: white; color: black;">
          <div class="">
            <span>{{ komorebi.focusedWorkspace.tilingContainers[komorebi.focusedWorkspace.focusedContainerIndex]?.windows[0]?.title ?? "-" }}</span>
          </div>
        </div>

Not sure if this is relevant., but I think that it is important to note that this does not happen right away. Zebar needs to run for a while, but this always happens eventually, forcing me to avoid the Komorebi provider.

Both the freezing issue and the catch-up issue are gone with the v2 🎉