[BUG]: YASB integration issue, started with latest build from master #296

Closed
opened 2026-01-05 14:49:33 +01:00 by adam · 7 comments
Owner

Originally created by @jpmiller25 on GitHub (Feb 15, 2024).

I am using YASB to show which workspace I'm on, and which workspaces have windows in them. I find it a necessary feature of a tiling manager workflow, and I hope there's intention of documenting and supporting some UI feature like this in the future, either yasb or rainmeter or something else.

The behavior is different from using the latest release vs. a current build from master. On the latest build, If I change to a workspace which does not have windows currently in it, the widget does not update. In order to update the state, I have to open a window in the new workspace, then switch to another, then switch back.

Expected behavior
When switching workspaces, the yasb widget reflects the change on a UI widget, regardless of whether there is a window in it already. This is correct when using the latest release version.

komorebic check Output

KOMOREBI_CONFIG_HOME detected: C:\Users\jmiller\.config\komorebi

Looking for configuration files in C:\Users\jmiller\.config\komorebi

Found komorebi.json; this file can be passed to the start command with the --config flag

Found C:\Users\jmiller\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag

YASB Config

watch_stylesheet: true
watch_config: true

bars:
  yasb-bar:
    enabled: true
    screens: ['*']
    class_name: "yasb-bar"
    alignment:
      position: "top"
      center: true
    blur_effect:
      enabled: false
      acrylic: false
      dark: false
    window_flags:
      always_on_top: true
      windows_app_bar: false
    dimensions:
      width: 400
      height: 32
    padding:
      top: 0
      left: 250
      bottom: 0
      right: 0
    widgets:
      center:   ["komorebi_active_layout", "komorebi_workspaces"]

widgets:
  komorebi_workspaces:
    type: "komorebi.workspaces.WorkspaceWidget"
    options:
        label_offline: "Komorebi Offline"
        label_workspace_btn: "{index}"
        label_default_name: "{index}"
        label_zero_index: false
        hide_empty_workspaces: false
  komorebi_active_layout:
    type: "komorebi.active_layout.ActiveLayoutWidget"
    options:
      hide_if_offline: false
 #       ^ Specifies if the active layout label should be shown when komorebi is offline
      label: "{icon}"
# ^ The label shown when an active layout change is detected. Accepts: string containing format options {icon} and {layout_name}
      layout_icons:
        bsp: "[\\]"
        columns: "[||]"
        rows: "[---]"
        vertical_stack: "[]="
        horizontal_stack: "H/="
        ultrawide_vertical_stack: "[|]="
        monocle: "[M]"
        maximised: "[X]"
        floating: "><>"
        paused: "|P|"
      callbacks:
#       ^ callback options include:
       #"next_layout" - Cycles the next layout for the active workspace
       #"prev_layout" - Cycles the previous layout for the active workspace
       #"flip_layout" - Flips layout of active workspace. Works for BSP tiling mode only
       #"toggle_tiling" - Toggles tiling of all windows for the active workspace
       #"toggle_float" - Toggles floating of active window for current workspace
       #"toggle_monocle" - Toggles monocle mode for active window for current workspace
       #"toggle_maximise" -  Toggles maximising active window for current workspace
       #"toggle_pause" - Toggles pausing komorebi on/off for all workspaces
        on_left: "next_layout"
        on_middle: "toggle_monocle"
        on_right: "prev_layout"

Originally created by @jpmiller25 on GitHub (Feb 15, 2024). I am using YASB to show which workspace I'm on, and which workspaces have windows in them. I find it a necessary feature of a tiling manager workflow, and I hope there's intention of documenting and supporting some UI feature like this in the future, either yasb or rainmeter or something else. The behavior is different from using the latest release vs. a current build from master. On the latest build, If I change to a workspace which does not have windows currently in it, the widget does not update. In order to update the state, I have to open a window in the new workspace, then switch to another, then switch back. **Expected behavior** When switching workspaces, the yasb widget reflects the change on a UI widget, regardless of whether there is a window in it already. This is correct when using the latest release version. **`komorebic check` Output** ``` KOMOREBI_CONFIG_HOME detected: C:\Users\jmiller\.config\komorebi Looking for configuration files in C:\Users\jmiller\.config\komorebi Found komorebi.json; this file can be passed to the start command with the --config flag Found C:\Users\jmiller\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag ``` **YASB Config** ``` watch_stylesheet: true watch_config: true bars: yasb-bar: enabled: true screens: ['*'] class_name: "yasb-bar" alignment: position: "top" center: true blur_effect: enabled: false acrylic: false dark: false window_flags: always_on_top: true windows_app_bar: false dimensions: width: 400 height: 32 padding: top: 0 left: 250 bottom: 0 right: 0 widgets: center: ["komorebi_active_layout", "komorebi_workspaces"] widgets: komorebi_workspaces: type: "komorebi.workspaces.WorkspaceWidget" options: label_offline: "Komorebi Offline" label_workspace_btn: "{index}" label_default_name: "{index}" label_zero_index: false hide_empty_workspaces: false komorebi_active_layout: type: "komorebi.active_layout.ActiveLayoutWidget" options: hide_if_offline: false # ^ Specifies if the active layout label should be shown when komorebi is offline label: "{icon}" # ^ The label shown when an active layout change is detected. Accepts: string containing format options {icon} and {layout_name} layout_icons: bsp: "[\\]" columns: "[||]" rows: "[---]" vertical_stack: "[]=" horizontal_stack: "H/=" ultrawide_vertical_stack: "[|]=" monocle: "[M]" maximised: "[X]" floating: "><>" paused: "|P|" callbacks: # ^ callback options include: #"next_layout" - Cycles the next layout for the active workspace #"prev_layout" - Cycles the previous layout for the active workspace #"flip_layout" - Flips layout of active workspace. Works for BSP tiling mode only #"toggle_tiling" - Toggles tiling of all windows for the active workspace #"toggle_float" - Toggles floating of active window for current workspace #"toggle_monocle" - Toggles monocle mode for active window for current workspace #"toggle_maximise" - Toggles maximising active window for current workspace #"toggle_pause" - Toggles pausing komorebi on/off for all workspaces on_left: "next_layout" on_middle: "toggle_monocle" on_right: "prev_layout" ```
adam added the bug label 2026-01-05 14:49:33 +01:00
adam closed this issue 2026-01-05 14:49:33 +01:00
Author
Owner

@azinsharaf commented on GitHub (Feb 15, 2024):

isn't it a yasb question, not komorebi?

@azinsharaf commented on GitHub (Feb 15, 2024): isn't it a yasb question, not komorebi?
Author
Owner

@jpmiller25 commented on GitHub (Feb 15, 2024):

Possibly but I asked here since it is working correctly on the release version but not on my build from source. I thought someone might know what may have recently changed in the komorebi mechanics that yasb is watching, which may explain the difference.

@jpmiller25 commented on GitHub (Feb 15, 2024): Possibly but I asked here since it is working correctly on the release version but not on my build from source. I thought someone might know what may have recently changed in the komorebi mechanics that yasb is watching, which may explain the difference.
Author
Owner

@azinsharaf commented on GitHub (Feb 16, 2024):

have you tired 0.1.21 version which was released after submitting this issue?

@azinsharaf commented on GitHub (Feb 16, 2024): have you tired 0.1.21 version which was released after submitting this issue?
Author
Owner

@jpmiller25 commented on GitHub (Feb 18, 2024):

I'll try the latest release either today or tomorrow, thanks

@jpmiller25 commented on GitHub (Feb 18, 2024): I'll try the latest release either today or tomorrow, thanks
Author
Owner

@jpmiller25 commented on GitHub (Feb 19, 2024):

The issue is present on the release 0.1.21. It was not present on the release 0.1.19.
I looked through the source of yasb and they have a lot of logic in python to connect to komorebi client and listen for events, there must be something happening on that side. I'll raise a bug report there.
I am very curious though what most people who use Komorebi are using for a UI widget, or if most don't use any? In searching I've found YASB, rainmeter, and komorebi-systray. I've found yasb to work the best so far but it still seems to often lose track of state. I wonder if a particular widget will end up getting more attention because more people are using it? or if it's possible to make komorebi have a cleaner api meant for widgets to consume and display the state.

@jpmiller25 commented on GitHub (Feb 19, 2024): The issue is present on the release 0.1.21. It was not present on the release 0.1.19. I looked through the source of yasb and they have a lot of logic in python to connect to komorebi client and listen for events, there must be something happening on that side. I'll raise a bug report there. I am very curious though what most people who use Komorebi are using for a UI widget, or if most don't use any? In searching I've found YASB, rainmeter, and komorebi-systray. I've found yasb to work the best so far but it still seems to often lose track of state. I wonder if a particular widget will end up getting more attention because more people are using it? or if it's possible to make komorebi have a cleaner api meant for widgets to consume and display the state.
Author
Owner

@LGUG2Z commented on GitHub (Feb 19, 2024):

I think this is probably something to be updated on the yasb side as you noted. Previously it was kind of tricky to code and integrate against certain internal structures in komorebi, however earlier today I exposed the komorebi internals directly to developers as a library (f519cbaf1e) and I am working on creating a versioned crate that developers who integrate with komorebi can use to version their dependency on komorebi and upgrade accordingly (8febaac9ff)

The main reason I'm doing this now is to see if we can get support for komorebi merged into zebar, which may be worth considering as an alternative to yasb in the future.

@LGUG2Z commented on GitHub (Feb 19, 2024): I think this is probably something to be updated on the `yasb` side as you noted. Previously it was kind of tricky to code and integrate against certain internal structures in `komorebi`, however earlier today I exposed the `komorebi` internals directly to developers as a library (https://github.com/LGUG2Z/komorebi/commit/f519cbaf1edf295f9435b413e9aa48a857b1eb00) and I am working on creating a versioned crate that developers who integrate with `komorebi` can use to version their dependency on `komorebi` and upgrade accordingly (https://github.com/LGUG2Z/komorebi/commit/8febaac9ff96de1cb22816defcc4b9ffbd644fc8) The main reason I'm doing this now is to see if we can get support for `komorebi` merged into [`zebar`](https://github.com/glzr-io/zebar), which may be worth considering as an alternative to `yasb` in the future.
Author
Owner

@jpmiller25 commented on GitHub (Feb 20, 2024):

@LGUG2Z Got it, All your work on this is very much appreciated!!

@jpmiller25 commented on GitHub (Feb 20, 2024): @LGUG2Z Got it, All your work on this is very much appreciated!!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#296