button-N CSS classes not applied visually after yasb 2.0.0

[efirlus]

Windows version

Windows 11

Windows OS build

windows 11 home 25H2

YASB version installed

2.0.0

Describe the bug

my komorebi workspace should look like this.

but after I update yasb from 1.9.0 to 2.0.0, it turns to

this. yellow icon and base background is my default widget color. it means no other button-specific css is not going well.

this bug is appeared at 1.8.5 once. I don't remember how to, when it fixed

my komorebi workspace config and css are here

  komorebi_workspaces:
    type: "komorebi.workspaces.WorkspaceWidget"
    options:
        label_offline: "Komorebi Offline"
        label_workspace_btn: "{name}"
        label_workspace_active_btn: "{name}"
        label_workspace_populated_btn: "{name}"
        label_default_name: "{index}"
        label_zero_index: false
        hide_empty_workspaces: false
        hide_if_offline: false

/* komorebi workspace */

.komorebi-workspaces {
    padding-left: 0;
    border-radius: 0;
}

.komorebi-workspaces .offline-status {
    color: var(--text3);
}

.komorebi-workspaces .ws-btn {
    font-size: 20px;
    background-color: transparent;
    border: none;
    margin: 0 0 0 0;
    padding: 7px 10px 7px 10px;
    color: var(--yellow);
}

.komorebi-workspaces .ws-btn.button-1,
.komorebi-workspaces .ws-btn.button-6 {
    border-top-left-radius: 6px;
    border-bottom-left-radius: 7px;
}

.komorebi-workspaces .ws-btn.button-1.active,
.komorebi-workspaces .ws-btn.button-6.active {
    background-color: var(--yellow);
    color: var(--base);
}

.komorebi-workspaces .ws-btn.button-5,
.komorebi-workspaces .ws-btn.button-8 {
    border-top-right-radius: 6px;
    border-bottom-right-radius: 6px;
}

.komorebi-workspaces .ws-btn.button-2,
.komorebi-workspaces .ws-btn.button-7 {
    color: var(--blue);
    background-color: transparent;
}

.komorebi-workspaces .ws-btn.button-2.active,
.komorebi-workspaces .ws-btn.button-7.active {
    background-color: var(--blue);
    color: var(--base);
}

.komorebi-workspaces .ws-btn.button-3,
.komorebi-workspaces .ws-btn.button-8 {
    color: var(--peach);
    background-color: transparent;
}

.komorebi-workspaces .ws-btn.button-3.active,
.komorebi-workspaces .ws-btn.button-8.active {
    background-color: var(--peach);
    color: var(--base);
}

.komorebi-workspaces .ws-btn.button-4 {
    color: var(--mauve);
    background-color: transparent;
}

.komorebi-workspaces .ws-btn.button-4.active {
    background-color: var(--mauve);
    color: var(--base);
}

.komorebi-workspaces .ws-btn.button-5 {
    color: var(--rosewater);
    background-color: transparent;
}

.komorebi-workspaces .ws-btn.button-5.active {
    background-color: var(--rosewater);
    color: var(--base);
}

.komorebi-workspaces .ws-btn:hover {
    color: var(--red);
}

.komorebi-workspaces .ws-btn.populated {
    background-color: #313244;
}

Relevant log output

no logs related to the komorebi-workspaces widget.

[Video-Nomad]

If you provide a CSS example with variables please also provide the variables.

[efirlus]

@Video-Nomad oh I forgot, sorry

:root {
    --mauve: #cba6f7;
    --red: #f38ba8;
    --rosewater: #f5e0dc;
    --yellow: #f9e2af;
    --peach: #fab387;
    --blue: #89b4fa;
    --lavender: #b4befe;
    --green: #a6e3a1;
    --text1: #cdd6f4;
    --text2: #bac2de;
    --text3: #a6adc8;
    --text4: #7f849e;
    --base: #1e1e2e;
    --mantle: #11111b;
}

[amnweb]

2026-05-05.11-26-47.mp4

This config and style you posted work fine for me.

[efirlus]

@amnweb yes, it should work perfectly fine.
chatgpt-5.5 and claude opus 4.7 assumed the problem, and added just 2 lines in komorebi/workspaces.py, and built from source, it works.

      60              new_class = " ".join([cls for cls in current_class.split() if not cls.sta
          rtswith("button-")])
      61              new_class = f"{new_class} button-{index + 1}"
      62              button.setProperty("class", new_class)
      63 +            refresh_widget_style(button)
      64
      65      def update_and_redraw(self, status: WorkspaceStatus):
      66          self.status = status

      128              new_class = " ".join([cls for cls in current_class.split() if not cls.st
           artswith("button-")])
      129              new_class = f"{new_class} button-{index + 1}"
      130              button.setProperty("class", new_class)
      131 +            refresh_widget_style(button)
      132
      133      def update_and_redraw(self, status: WorkspaceStatus):
      134          self.status = status

I don't understand properly, but they said

 Qt's stylesheet engine doesn't re-evaluate dynamic properties on setProperty alone — unpolish/polish must be called explicitly. Since `update_visible_buttons` assigns the button-N class after `update_and_redraw` already called `refresh_widget_style`, the stylesheet never sees the button-N class, causing any CSS rules that require it (per-button colors, .button-N.active) to silently not apply.
  Adding refresh_widget_style(button) after each setProperty call here matches the existing pattern already used correctly in stack.py.

This would also explain why the issue is environment/order dependent and hard to reproduce: a later global stylesheet reload can mask the problem, but normal runtime class updates won't trigger a repolish.

[amnweb]

So without refresh_widget_style(button) it does not work for you?

[efirlus]

@amnweb yes. without state -> yellow color.
I think it's caused by 'update' method, in my case.
I was installed yasb via winget at version 1.2 or 1.3, and after 1.6, I changed update method to curl script. get latest release from repo and autoinstall. monthly script.

[amnweb]

@amnweb yes. without state -> yellow color. I think it's caused by 'update' method, in my case. I was installed yasb via winget at version 1.2 or 1.3, and after 1.6, I changed update method to curl script. get latest release from repo and autoinstall. monthly script.

Can you test version 1.9.1 and let me know if that works for you?

[efirlus]

@amnweb I found very interesting thing.
css is worked at 1.9.1. however, when I update from 1.9.1 to 2.0.0, komorebi workspaces buttons turned back to yellow.

interesting....

claude answered to this

  In v1.9.1, update_visible_buttons() called button.setStyleSheet("") after assigning the button-N
  class, which forced Qt to re-evaluate the stylesheet. In v2.0.0, this line was removed but no
  replacement (like refresh_widget_style()) was added, so Qt never sees the button-N class during
  style computation. The fix is to call refresh_widget_style(button) after button.setProperty("class",
   new_class) in update_visible_buttons() — this restores the unpolish/polish cycle that was
  implicitly handled by setStyleSheet("") in 1.9.1.

  After further tracing the call order: bar.setStyleSheet() only fires at startup and on CSS file save
   — those are the only moments Qt re-polishes all child widgets, which is when button-N classes
  (already set by update_visible_buttons()) get picked up correctly. During workspace switching,
  update_and_redraw() resets the button class to ws-btn {status} and calls refresh_widget_style(),
  then update_visible_buttons() re-appends button-N with no refresh following it. Since no global
  stylesheet re-evaluation happens after that point, Qt never sees the updated button-N class —
  causing the button to render with default CSS until the next full stylesheet reload.

obviously I don't understand at all

[amnweb]

Don't spend money on AI, just let me know if v1.9.1 works for you as it should be

[efirlus]

@amnweb already answered. 1.9.1 is worked.

[amnweb]

Thanks

[mi-zar0]

how to get the 1.9.1 version cause komorebi workspaces animation dosen't work like the video sent here earlier by amnweb

[efirlus]

@mi-zar0

how to get the 1.9.1 version cause komorebi workspaces animation dosen't work like the video sent here earlier by amnweb

Here

[efirlus]

@amnweb perfectly works with your fix (I ran current repo main branch)
thank you for the help