Expected behavior
The stackbar does not disappear.
Screenshots of the bug before and after Zebar is started
Operating System
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.22631 N/A Build 22631
komorebic check Output
No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\[UserName]
Looking for configuration files in C:\Users\[UserName]
Found komorebi.json; this file can be passed to the start command with the --config flag
Found C:\Users\[UserName]\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag
Additional context
I built Zebar locally, since I am working on some additions to the project. There has been no updates to Zebar since I started working on it. I did not modify core features of it, just modified a provider, which makes me believe that this issue is not related to anything I did locally. However, if this issue cannot be reproduced by others or the issue is with Zebar and not Komorebi, I am more than happy to move this there instead.
Lastly, thank you for your great work on this project!
Originally created by @CtByte on GitHub (Apr 13, 2024).
**Describe the bug**
The stackbar disappears when Zebar is started.
**To Reproduce**
Steps to reproduce the behavior:
1. Start Komorebi
2. Open 2 or more windows and stack them together
3. Install [Zebar](https://github.com/glzr-io/zebar) and start it using the [bat file](https://github.com/glzr-io/zebar/blob/main/packages/desktop/resources/start.bat)
4. See bug
**Expected behavior**
The stackbar does not disappear.
**Screenshots of the bug before and after Zebar is started**
<img width="382" alt="Screenshot 2024-04-13 170841" src="https://github.com/LGUG2Z/komorebi/assets/165908630/8cc1a092-7d8d-47d8-ac9d-e01ace928cba">
<img width="308" alt="Screenshot 2024-04-13 170938" src="https://github.com/LGUG2Z/komorebi/assets/165908630/a5ce1bc2-ccf4-4600-8570-063ff06fa75f">
**Operating System**
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.22631 N/A Build 22631
**`komorebic check` Output**
```
No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\[UserName]
Looking for configuration files in C:\Users\[UserName]
Found komorebi.json; this file can be passed to the start command with the --config flag
Found C:\Users\[UserName]\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag
```
**Additional context**
I built Zebar locally, since I am working on some additions to the project. There has been no updates to Zebar since I started working on it. I did not modify core features of it, just modified a provider, which makes me believe that this issue is not related to anything I did locally. However, if this issue cannot be reproduced by others or the issue is with Zebar and not Komorebi, I am more than happy to move this there instead.
Lastly, thank you for your great work on this project!
adam
added the bug label 2026-01-05 14:49:47 +01:00
while Zebar is running I stack and unstack windows. The stackbar did not appear.
while Zebar is running I stack windows => No stackbar => Stop Zebar => Still no stackbar => unstack then stack windows => the stackbar appears => Start Zebar => no stackbar
I could not think of more test cases
@CtByte commented on GitHub (Apr 13, 2024):
@LGUG2Z
I tried the following:
1. while Zebar is running I stack and unstack windows. The stackbar did not appear.
2. while Zebar is running I stack windows => No stackbar => Stop Zebar => Still no stackbar => unstack then stack windows => the stackbar appears => Start Zebar => no stackbar
I could not think of more test cases
If anyone uses yasb I'd be interested to know if this also happens when running yasb; it would help to know if this is reproducible across multiple topbars or if it's just something with the interactions between komorebi and zebar.
@LGUG2Z commented on GitHub (Apr 13, 2024):
If anyone uses yasb I'd be interested to know if this also happens when running yasb; it would help to know if this is reproducible across multiple topbars or if it's just something with the interactions between komorebi and zebar.
@LGUG2Z
It was not easy to install, but I gave it a try.
Ignore all the extra space between the stackbar and yasb, as I still have my offset for Zebar.
I tried to stack and unstack many times, and it worked just fine. As far as I can tell, yasb has a pretty good implementation for Komorebi, but I would like to stick with Zebar (as the last yasb update was over 5 month ago and has many issues open).
I am not sure at this point, if the issue is with the Zebar implementation or some kind of Rust related issue.
@CtByte commented on GitHub (Apr 13, 2024):
@LGUG2Z
It was not easy to install, but I gave it a try.
<img width="358" alt="Screenshot 2024-04-13 200112" src="https://github.com/LGUG2Z/komorebi/assets/165908630/878c7602-087c-4f0d-8d48-bed2825126db">
Ignore all the extra space between the stackbar and yasb, as I still have my offset for Zebar.
I tried to stack and unstack many times, and it worked just fine. As far as I can tell, yasb has a pretty good implementation for Komorebi, but I would like to stick with Zebar (as the last yasb update was over 5 month ago and has many issues open).
I am not sure at this point, if the issue is with the Zebar implementation or some kind of Rust related issue.
@LGUG2Z
I did some more testing and it seems like that something happened in komorebi v0.1.23, because when I run Zebar locally (first unmodified release then my modified version of Zebar), I change the Komorebi version here and I get the following result:
v0.1.22 works with the stackbar with Zebar v1.3 (unmodified)
v0.1.23 and v0.1.24 do not work with the stackbar with Zebar v1.3 (unmodified)
v0.1.22 works with the stackbar with Zebar v1.3 (modified by me)
v0.1.23 does not work with the stackbar with Zebar v1.3 (modified by me)
I hope this helps in hunting down this bug
@CtByte commented on GitHub (Apr 15, 2024):
@LGUG2Z
I did some more testing and it seems like that something happened in komorebi v0.1.23, because when I run Zebar locally (first unmodified release then my modified version of Zebar), I change the Komorebi version [here](https://github.com/glzr-io/zebar/blob/e565ce605bf2bc18efd352f73a988d5ab5d76d2b/packages/desktop/Cargo.toml#L36) and I get the following result:
v0.1.22 works with the stackbar with Zebar v1.3 (unmodified)
<img width="358" alt="Screenshot 2024-04-15 212811 v0 1 22 " src="https://github.com/LGUG2Z/komorebi/assets/165908630/9a5122f8-6806-4592-9242-6f195e70fab3">
v0.1.23 and v0.1.24 do not work with the stackbar with Zebar v1.3 (unmodified)
<img width="309" alt="Screenshot 2024-04-15 213357" src="https://github.com/LGUG2Z/komorebi/assets/165908630/576c72a3-578c-48e4-b348-f56bc8f7b829">
<img width="296" alt="Screenshot 2024-04-15 213510" src="https://github.com/LGUG2Z/komorebi/assets/165908630/6d5d0bad-8ffb-489f-88dc-0bdf91a508f7">
v0.1.22 works with the stackbar with Zebar v1.3 (modified by me)
<img width="412" alt="Screenshot 2024-04-15 213951" src="https://github.com/LGUG2Z/komorebi/assets/165908630/be59bad6-549d-4a77-ace7-b03d3ee89845">
v0.1.23 does not work with the stackbar with Zebar v1.3 (modified by me)
<img width="425" alt="Screenshot 2024-04-15 214037" src="https://github.com/LGUG2Z/komorebi/assets/165908630/81cf9ed7-588d-4285-adee-8e4b22e08911">
I hope this helps in hunting down this bug
The stackbars will reappear if sending a message to change the stackbar mode from Never to Always/OnStack via komorebi-egui on the feature/egui branch (requires komorebi to be installed from the same commit), so it looks like the stackbar is salvagable after one of these events, just need to dig to try and avoid this happening in the first place. cc @raggi
@LGUG2Z commented on GitHub (Apr 16, 2024):
The stackbars will reappear if sending a message to change the stackbar mode from Never to Always/OnStack via `komorebi-egui` on the feature/egui branch (requires `komorebi` to be installed from the same commit), so it looks like the stackbar is salvagable after one of these events, just need to dig to try and avoid this happening in the first place. cc @raggi
@CtByte not sure if you're able to build locally, but if you can, would you try building komorebi/komorebic/komorebi-egui from the feature/egui branch and then toggling the stackbar mode to Never and then to Always or OnStack after you have launched zebar and the stackbars initially disappear?
@LGUG2Z commented on GitHub (Apr 16, 2024):
@CtByte not sure if you're able to build locally, but if you can, would you try building komorebi/komorebic/komorebi-egui from the feature/egui branch and then toggling the stackbar mode to Never and then to Always or OnStack after you have launched zebar and the stackbars initially disappear?

@LGUG2Z I will try my best to help you out. I have a few busy days ahead so it might take some time before I could get back to you with some results (I might have some questions regarding that).
I appreciate all the effort going into hunting this bug down :)
@CtByte commented on GitHub (Apr 16, 2024):
@LGUG2Z I will try my best to help you out. I have a few busy days ahead so it might take some time before I could get back to you with some results (I might have some questions regarding that).
I appreciate all the effort going into hunting this bug down :)
I'm not quite sure what's causing the hiding behavior/haven't had a chance to repro this yet. I can hopefully take a look after work tonight.
Some thoughts in the meantime:
The stackbar wants to be visible and "on top" most of the time - but not unconditionally on top
If there is a floating foreground window, the stackbar should not raise itself above that foreground window
If there is a floating window that is not foreground, but it is above the stack, the associated stackbar window should not paint over that floating window either
So in slightly simpler terms, the stackbar should regularly update itself on foreground window changes/stack changes to:
let stack_top_hwnd = self.my_stack.current_top_hwnd();
SetWindowPos(stackbar_hwnd, stack_top_hwnd, x, y, cx, cy, SWP_NOACTIVATE);
This is similar to, but slightly different from the border window: The border window regularly raises itself to HWND_TOP, except it also hides itself when a non-managed window is made foreground_window, which is what prevents it from drawing over other windows (as there's only one). If we later make a border window per managed window (something we're talking about) then the rules get more fancy, where it would need to find the window it's wrapping and always position itself exaclty above that window in the z-order (not top, not topmost, etc).
Note that something like self.my_stack.current_top_hwnd() might be slightly painful to add right now. I suspect we can approximate this behavior quickly by instead setting ourselves to just underneath the foreground window all the time (WindowsApi::foreground_window()) - this would be imperfect, if you have two floating windows, one recently foreground, one now foreground, the stackbar would draw over the top of the recently foreground floating window - messy & not ideal, but still usable as a first step.
@raggi commented on GitHub (Apr 16, 2024):
I'm not quite sure what's causing the hiding behavior/haven't had a chance to repro this yet. I can hopefully take a look after work tonight.
Some thoughts in the meantime:
- The stackbar wants to be visible and "on top" most of the time - but not unconditionally on top
- If there is a floating foreground window, the stackbar should not raise itself above that foreground window
- If there is a floating window that is not foreground, but it is above the stack, the associated stackbar window should not paint over that floating window either
So in slightly simpler terms, the stackbar should regularly update itself on foreground window changes/stack changes to:
let stack_top_hwnd = self.my_stack.current_top_hwnd();
SetWindowPos(stackbar_hwnd, stack_top_hwnd, x, y, cx, cy, SWP_NOACTIVATE);
This is similar to, but slightly different from the border window: The border window regularly raises itself to HWND_TOP, except it also hides itself when a non-managed window is made foreground_window, which is what prevents it from drawing over other windows (as there's only one). If we later make a border window per managed window (something we're talking about) then the rules get more fancy, where it would need to find the window it's wrapping and always position itself exaclty above that window in the z-order (not top, not topmost, etc).
Note that something like `self.my_stack.current_top_hwnd()` might be slightly painful to add right now. I suspect we can approximate this behavior quickly by instead setting ourselves to just underneath the foreground window all the time (`WindowsApi::foreground_window()`) - this would be imperfect, if you have two floating windows, one recently foreground, one now foreground, the stackbar would draw over the top of the recently foreground floating window - messy & not ideal, but still usable as a first step.
Stackbar disappears for me when I resume from sleep
Stackbar reappears after resuming from sleep if I switch to another workspace and back
@LGUG2Z commented on GitHub (Apr 17, 2024):
More data points:
* Stackbar disappears for me when I resume from sleep
* Stackbar reappears after resuming from sleep if I switch to another workspace and back
@LGUG2Z I tried to run komorebi from the feature/egui branch. I managed kinda, but I would like to detail what I did, as I started learning Rust 2-3 weeks ago ( thanks to you :D ) and I want to make sure I am doing the right thing.
ran the ...\LGUG2Z\komorebi>cargo build command
ran the ...\LGUG2Z\komorebi\target\debug>komorebi.exe command
ran the ...\LGUG2Z\komorebi\target\debug>komorebic.exe start --whkd command in a new console
Here is the result: stackbar mode=OnStack
stackbar mode=Never
stackbar mode=Always
Clicking on the stackbar also worked, it changed the window.
The next step was to run the komorebi-egui.
When I ran the ...\LGUG2Z\komorebi\target\debug>.\komorebi-egui.exe command I got this error (not sure how to run with RUST_BACKTRACE=1):
...\LGUG2Z\komorebi\target\debug> .\komorebi-egui.exe
thread 'main' panicked at komorebi-egui\src\main.rs:68:10:
called `Result::unwrap()` on an `Err` value: Error("missing field `unmanaged_window_operation_behaviour`", line: 1374, column: 1)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I tried to add the setting as stated here, but it gave a new error (new line number)
...\LGUG2Z\komorebi\target\debug> .\komorebi-egui.exe
thread 'main' panicked at komorebi-egui\src\main.rs:68:10:
called `Result::unwrap()` on an `Err` value: Error("missing field `unmanaged_window_operation_behaviour`", line: 1416, column: 1)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I am probably doing something wrong, could you please let me know what?
@CtByte commented on GitHub (Apr 17, 2024):
@LGUG2Z I tried to run komorebi from the ``feature/egui`` branch. I managed kinda, but I would like to detail what I did, as I started learning Rust 2-3 weeks ago ( thanks to you :D ) and I want to make sure I am doing the right thing.
1. ran the **...\LGUG2Z\komorebi>** `cargo build` command
2. ran the **...\LGUG2Z\komorebi\target\debug>** `komorebi.exe` command
3. ran the **...\LGUG2Z\komorebi\target\debug>** `komorebic.exe start --whkd` command in a new console
Here is the result:
`stackbar mode=OnStack`
<img width="572" alt="Screenshot 2024-04-17 181924" src="https://github.com/LGUG2Z/komorebi/assets/165908630/476cd794-b123-451a-99e4-874e8b5a62d1">
`stackbar mode=Never`
<img width="398" alt="Screenshot 2024-04-17 182307" src="https://github.com/LGUG2Z/komorebi/assets/165908630/c7f5834d-d796-4083-8fff-b6737a97419d">
`stackbar mode=Always`
<img width="1140" alt="Screenshot 2024-04-17 182607" src="https://github.com/LGUG2Z/komorebi/assets/165908630/319d7f0b-2ad4-4e03-90bf-f1d4f7a2af7f">
Clicking on the stackbar also worked, it changed the window.
The next step was to run the komorebi-egui.
When I ran the **...\LGUG2Z\komorebi\target\debug>** `.\komorebi-egui.exe` command I got this error (not sure how to run with `RUST_BACKTRACE=1`):
````
...\LGUG2Z\komorebi\target\debug> .\komorebi-egui.exe
thread 'main' panicked at komorebi-egui\src\main.rs:68:10:
called `Result::unwrap()` on an `Err` value: Error("missing field `unmanaged_window_operation_behaviour`", line: 1374, column: 1)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
````
I tried to add the setting as stated [here](https://komorebi.lgug2z.com/schema#unmanaged_window_operation_behaviour), but it gave a new error (new line number)
<img width="485" alt="Screenshot 2024-04-17 184446" src="https://github.com/LGUG2Z/komorebi/assets/165908630/3f4499e2-c610-4ae4-89e0-f8d5a584e78b">
````
...\LGUG2Z\komorebi\target\debug> .\komorebi-egui.exe
thread 'main' panicked at komorebi-egui\src\main.rs:68:10:
called `Result::unwrap()` on an `Err` value: Error("missing field `unmanaged_window_operation_behaviour`", line: 1416, column: 1)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
````
I am probably doing something wrong, could you please let me know what?
One thing I did wrong is that I did not stop Zebar before tests....sorry about that. But now I know that if Komorebi is started after Zebar then the stackbar works.
So, what I also did was:
Stopped Zebar
ran the ...\LGUG2Z\komorebi\target\debug>.\komorebi.exe command
ran the ...\LGUG2Z\komorebi\target\debug>.\komorebic.exe start --whkd command in a new console
Started Zebar
What I think you find more useful is that in each mode (Never,OnStack,Always) the stackbar disappeared and when I clicked on a window, this warning came in the console:
I hope this is more useful, and if you want me to do more tests, please let me know (also if I missed something).
Can this be a Zebar related issue?
@CtByte commented on GitHub (Apr 17, 2024):
One thing I did wrong is that I did not stop Zebar before tests....sorry about that. But now I know that if Komorebi is started after Zebar then the stackbar works.
So, what I also did was:
1. Stopped Zebar
2. ran the **...\LGUG2Z\komorebi\target\debug>** `.\komorebi.exe` command
3. ran the **...\LGUG2Z\komorebi\target\debug>** `.\komorebic.exe start --whkd` command in a new console
4. Started Zebar
What I think you find more useful is that in each mode (Never,OnStack,Always) the stackbar disappeared and when I clicked on a window, this warning came in the console:
````
2024-04-17T17:23:41.649317Z WARN process_event{event=FocusChange(SystemForeground, Window { hwnd: 789702 })}: komorebi: removing stale subscription: zebar.sock
````
I hope this is more useful, and if you want me to do more tests, please let me know (also if I missed something).
Can this be a Zebar related issue?
An other thing I noticed is that the Komorebi provider in Zebar is not working when I run it from the feature/egui branch, but it still works for me when I run "my modified" Zebar with Komorebi v0.1.24. Others have problem with the latest Komorebi version after updating.
@CtByte commented on GitHub (Apr 17, 2024):
An other thing I noticed is that the Komorebi provider in Zebar is not working when I run it from the `feature/egui` branch, but it still works for me when I run "my modified" Zebar with Komorebi v0.1.24. [Others have problem](https://github.com/glzr-io/zebar/issues/52) with the latest Komorebi version after updating.
@CtByte it looks like you're running komorebic start which will look for the komorebi.exe in your $Env:PATH and not in the target/debug folder. The best way around this is to run the cargo install command instead of the cargo build command, and usually this will put the binary in an output folder that is both in the PATH and one that has a higher priority than other installed binaries with the same name.
@LGUG2Z commented on GitHub (Apr 18, 2024):
@CtByte it looks like you're running `komorebic start` which will look for the `komorebi.exe` in your `$Env:PATH` and not in the `target/debug` folder. The best way around this is to run the `cargo install` command instead of the `cargo build` command, and usually this will put the binary in an output folder that is both in the PATH and one that has a higher priority than other installed binaries with the same name.
I start Zebar and any stackbars I had, disappeared
As you can see in the logs, I clicked the never/onstack/always options for the stackbar in the egui
The stackbars appear again when I am clicking.
(I do get a WARNing and the Komorebi provider of Zebar does not show up, but that is for another time)
2024-04-18T17:29:47.817575Z INFO process_command{AddSubscriberSocket("zebar.sock")}: komorebi::process_command: processed
2024-04-18T17:29:53.688123Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor
2024-04-18T17:29:53.688310Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}:focus_window{idx=0}: komorebi::container: focusing window
2024-04-18T17:29:53.696421Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}:update_focused_workspace{follow_focus=true trigger_focus=false}: komorebi::window_manager: updating
2024-04-18T17:29:53.702605Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}:focus_window{idx=0}: komorebi::container: focusing window
2024-04-18T17:29:53.702934Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}:focus_container{idx=0}: komorebi::workspace: focusing container
2024-04-18T17:29:53.704612Z WARN process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}: komorebi: removing stale subscription: zebar.sock
2024-04-18T17:29:53.704864Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}: komorebi::process_event: processed: (hwnd: 2753300, title: komorebi-egui, exe: komorebi-egui.exe, class: Window Class)
2024-04-18T17:29:53.776427Z INFO process_command{StackbarMode(Never)}: komorebi::process_command: processed
2024-04-18T17:29:53.793814Z INFO process_command{Retile}: komorebi::process_command: processed
2024-04-18T17:29:56.157769Z INFO process_command{StackbarMode(OnStack)}: komorebi::process_command: processed
2024-04-18T17:29:56.175399Z INFO process_command{Retile}: komorebi::process_command: processed
2024-04-18T17:29:59.378192Z INFO process_command{StackbarMode(Always)}: komorebi::process_command: processed
2024-04-18T17:29:59.404431Z INFO process_command{Retile}: komorebi::process_command: processed
2024-04-18T17:30:10.678899Z INFO process_command{StackbarMode(OnStack)}: komorebi::process_command: processed
2024-04-18T17:30:10.725425Z INFO process_command{Retile}: komorebi::process_command: processed
2024-04-18T17:30:15.179551Z INFO process_command{StackbarMode(Never)}: komorebi::process_command: processed
2024-04-18T17:30:15.192355Z INFO process_command{Retile}: komorebi::process_command: processed
2024-04-18T17:30:17.570354Z INFO process_command{StackbarMode(Always)}: komorebi::process_command: processed
2024-04-18T17:30:17.592784Z INFO process_command{Retile}: komorebi::process_command: processed
2024-04-18T17:30:23.604804Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 136444 })}:focus_monitor{idx=1}: komorebi::window_manager: focusing monitor
2024-04-18T17:30:23.608875Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 136444 })}:focus_window{idx=0}:
komorebi::container: focusing window
2024-04-18T17:30:23.615603Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 136444 })}:update_focused_workspace{follow_focus=true trigger_focus=false}: komorebi::window_manager: updating
2024-04-18T17:30:23.619976Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 136444 })}:focus_window{idx=0}:
komorebi::container: focusing window
2024-04-18T17:30:23.620106Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 136444 })}:focus_container{idx=0}: komorebi::workspace: focusing container
2024-04-18T17:30:23.621501Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 136444 })}: komorebi::process_event: processed: (hwnd: 136444, title: Developer PowerShell Visual Studio Community 2022 17.9.34728.123, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS)
I hope that this is what you asked me to do.
@CtByte commented on GitHub (Apr 18, 2024):
@LGUG2Z Thank you, that makes sense, I managed to use install from [here](https://lgug2z.github.io/komorebi/installation.html#building-from-source)
1. In the **...\LGUG2Z\komorebi** I ran these
````
cargo +stable install --path komorebi --locked
cargo +stable install --path komorebic --locked
cargo +stable install --path komorebic-no-console --locked
cargo +stable install --path komorebi-egui --locked
````
2. Copied the .exe files from `c:\Users\<username>\.cargo\bin\` to `c:\Program Files\komorebi\bin\` where my `$Env:PATH` pointed to for good measure.
3. Then I ran these commands in `...\LGUG2Z\komorebi\target\debug>`
````
.\komorebi.exe
.\komorebic.exe start --whkd
.\komorebi-egui.exe
````
4. Now I have the gui as well
5. I start Zebar and any stackbars I had, disappeared
6. As you can see in the logs, I clicked the never/onstack/always options for the stackbar in the egui
7. The stackbars appear again when I am clicking.
8. (I do get a `WARN`ing and the Komorebi provider of Zebar does not show up, but that is for another time)
````
2024-04-18T17:29:47.817575Z INFO process_command{AddSubscriberSocket("zebar.sock")}: komorebi::process_command: processed
2024-04-18T17:29:53.688123Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}:focus_monitor{idx=0}: komorebi::window_manager: focusing monitor
2024-04-18T17:29:53.688310Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}:focus_window{idx=0}: komorebi::container: focusing window
2024-04-18T17:29:53.696421Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}:update_focused_workspace{follow_focus=true trigger_focus=false}: komorebi::window_manager: updating
2024-04-18T17:29:53.702605Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}:focus_window{idx=0}: komorebi::container: focusing window
2024-04-18T17:29:53.702934Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}:focus_container{idx=0}: komorebi::workspace: focusing container
2024-04-18T17:29:53.704612Z WARN process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}: komorebi: removing stale subscription: zebar.sock
2024-04-18T17:29:53.704864Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 2753300 })}: komorebi::process_event: processed: (hwnd: 2753300, title: komorebi-egui, exe: komorebi-egui.exe, class: Window Class)
2024-04-18T17:29:53.776427Z INFO process_command{StackbarMode(Never)}: komorebi::process_command: processed
2024-04-18T17:29:53.793814Z INFO process_command{Retile}: komorebi::process_command: processed
2024-04-18T17:29:56.157769Z INFO process_command{StackbarMode(OnStack)}: komorebi::process_command: processed
2024-04-18T17:29:56.175399Z INFO process_command{Retile}: komorebi::process_command: processed
2024-04-18T17:29:59.378192Z INFO process_command{StackbarMode(Always)}: komorebi::process_command: processed
2024-04-18T17:29:59.404431Z INFO process_command{Retile}: komorebi::process_command: processed
2024-04-18T17:30:10.678899Z INFO process_command{StackbarMode(OnStack)}: komorebi::process_command: processed
2024-04-18T17:30:10.725425Z INFO process_command{Retile}: komorebi::process_command: processed
2024-04-18T17:30:15.179551Z INFO process_command{StackbarMode(Never)}: komorebi::process_command: processed
2024-04-18T17:30:15.192355Z INFO process_command{Retile}: komorebi::process_command: processed
2024-04-18T17:30:17.570354Z INFO process_command{StackbarMode(Always)}: komorebi::process_command: processed
2024-04-18T17:30:17.592784Z INFO process_command{Retile}: komorebi::process_command: processed
2024-04-18T17:30:23.604804Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 136444 })}:focus_monitor{idx=1}: komorebi::window_manager: focusing monitor
2024-04-18T17:30:23.608875Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 136444 })}:focus_window{idx=0}:
komorebi::container: focusing window
2024-04-18T17:30:23.615603Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 136444 })}:update_focused_workspace{follow_focus=true trigger_focus=false}: komorebi::window_manager: updating
2024-04-18T17:30:23.619976Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 136444 })}:focus_window{idx=0}:
komorebi::container: focusing window
2024-04-18T17:30:23.620106Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 136444 })}:focus_container{idx=0}: komorebi::workspace: focusing container
2024-04-18T17:30:23.621501Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 136444 })}: komorebi::process_event: processed: (hwnd: 136444, title: Developer PowerShell Visual Studio Community 2022 17.9.34728.123, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS)
````
I hope that this is what you asked me to do.
@LGUG2Z I have a small update on this, I hope this helps. It seems that the stackbar only disappears when I use the Komorebi provider in Zebar.
I started Komorebi, stacked a few windows like before, started Zebar without using the Komorebi provider, and the stackbar did not disappear.
I am using Komorebi v0.1.24. If you need me to test more, please let me know.
@CtByte commented on GitHub (Apr 24, 2024):
@LGUG2Z I have a small update on this, I hope this helps. It seems that the stackbar only disappears when I use the Komorebi provider in Zebar.
I started Komorebi, stacked a few windows like before, started Zebar without using the Komorebi provider, and the stackbar did not disappear.
I am using Komorebi v0.1.24. If you need me to test more, please let me know.
I've pinned this issue to give it a bit more visibility on the tracker and hopefully attract people with new ideas about how to fix this bug.
@LGUG2Z commented on GitHub (Apr 29, 2024):
Another way to reproduce this issue here: https://github.com/LGUG2Z/komorebi/issues/792
I've pinned this issue to give it a bit more visibility on the tracker and hopefully attract people with new ideas about how to fix this bug.
@tgrosinger I believe 611fa34 fixes the stackbar disappearing with reloads 🎉
It turns out that the stackbar windows are disappearing because of actions in various code paths that result in Drop being called. To make these a little easier to track down I've added a debug log whenever a stackbar window is being dropped:
@CtByte I don't have Zebar set up myself, but maybe you can see if this makes any difference for you?
@LGUG2Z commented on GitHub (Apr 29, 2024):
@tgrosinger I believe [611fa34](https://github.com/LGUG2Z/komorebi/commit/611fa3456703e8804ab708831694425894ad79f7) fixes the stackbar disappearing with reloads 🎉
It turns out that the stackbar windows are disappearing because of actions in various code paths that result in `Drop` being called. To make these a little easier to track down I've added a debug log whenever a stackbar window is being dropped:
https://github.com/LGUG2Z/komorebi/blob/611fa3456703e8804ab708831694425894ad79f7/komorebi/src/stackbar.rs#L77
@CtByte I don't have Zebar set up myself, but maybe you can see if this makes any difference for you?
@CtByte 7cab062 should be the fix for Zebar as well!
cc @lars-berger 🎉
@LGUG2Z commented on GitHub (Apr 30, 2024):
@CtByte [7cab062](https://github.com/LGUG2Z/komorebi/commit/7cab0621243c8bbaee83fe200c0724d5b77dcff5) should be the fix for Zebar as well!
cc @lars-berger 🎉
@LGUG2Z Thank you so much for looking into this! I will validate the fix with Zebar very soon, so we can close this issue.
@CtByte commented on GitHub (Apr 30, 2024):
@LGUG2Z Thank you so much for looking into this! I will validate the fix with Zebar very soon, so we can close this issue.
@LGUG2Z I tried both ways to reproduce this issue (Zebar and #792)
I can verify that the issue with the config reloading is solved.
I had to add the new layout (RightMainVerticalStack) to Zebar and ran it on this rev komorebi-client = { git = "https://github.com/LGUG2Z/komorebi", rev = "871a53821c3bc7866f479132d060fe8a8e902c21" }
The issue with the stackbar is solved 🎉
The only problem is that Zebar needs to be changed for the fix to take affect.
So if the Cargo.toml is using the newest rev and the komorebi\variables.rs is updated then it should work.
I can wait making the pull request until perhaps the next release of Komorebi, so then not the rev, but the tag would be used.
What do you think? Can this issue be closed now or I should wait until Zebar is updated?
@CtByte commented on GitHub (Apr 30, 2024):
@LGUG2Z I tried both ways to reproduce this issue (Zebar and #792)
I can verify that the issue with the config reloading is solved.
I had to add the new layout (RightMainVerticalStack) to Zebar and ran it on this rev
`komorebi-client = { git = "https://github.com/LGUG2Z/komorebi", rev = "871a53821c3bc7866f479132d060fe8a8e902c21" }`
The issue with the stackbar is solved 🎉
The only problem is that Zebar needs to be changed for the fix to take affect.
<img width="985" alt="Screenshot 2024-04-30 200617" src="https://github.com/LGUG2Z/komorebi/assets/165908630/a2ffa3bf-5fb1-4fae-8b4a-fef3a10752e8">
So if the `Cargo.toml` is using the newest rev and the `komorebi\variables.rs` is updated then it should work.
I can wait making the pull request until perhaps the next release of Komorebi, so then not the rev, but the tag would be used.
What do you think? Can this issue be closed now or I should wait until Zebar is updated?
@CtByte commented on GitHub (May 1, 2024):
@LGUG2Z Thank you very much for your help!
I did what I can for [Zebar](https://github.com/glzr-io/zebar/pull/59)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @CtByte on GitHub (Apr 13, 2024).
Describe the bug
The stackbar disappears when Zebar is started.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The stackbar does not disappear.
Screenshots of the bug before and after Zebar is started


Operating System
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.22631 N/A Build 22631
komorebic checkOutputAdditional context
I built Zebar locally, since I am working on some additions to the project. There has been no updates to Zebar since I started working on it. I did not modify core features of it, just modified a provider, which makes me believe that this issue is not related to anything I did locally. However, if this issue cannot be reproduced by others or the issue is with Zebar and not Komorebi, I am more than happy to move this there instead.
Lastly, thank you for your great work on this project!
@LGUG2Z commented on GitHub (Apr 13, 2024):
It's likely an issue with komorebi. Does the stackbar reappear if you unstack and then restack?
@CtByte commented on GitHub (Apr 13, 2024):
@LGUG2Z
I tried the following:
I could not think of more test cases
@LGUG2Z commented on GitHub (Apr 13, 2024):
If anyone uses yasb I'd be interested to know if this also happens when running yasb; it would help to know if this is reproducible across multiple topbars or if it's just something with the interactions between komorebi and zebar.
@CtByte commented on GitHub (Apr 13, 2024):
@LGUG2Z
It was not easy to install, but I gave it a try.
Ignore all the extra space between the stackbar and yasb, as I still have my offset for Zebar.
I tried to stack and unstack many times, and it worked just fine. As far as I can tell, yasb has a pretty good implementation for Komorebi, but I would like to stick with Zebar (as the last yasb update was over 5 month ago and has many issues open).
I am not sure at this point, if the issue is with the Zebar implementation or some kind of Rust related issue.
@LGUG2Z commented on GitHub (Apr 15, 2024):
@lars-berger any ideas? 👀
@CtByte commented on GitHub (Apr 15, 2024):
Can it be confirmed that this is not just me? I would feel much better :)
@CtByte commented on GitHub (Apr 15, 2024):
@LGUG2Z
I did some more testing and it seems like that something happened in komorebi v0.1.23, because when I run Zebar locally (first unmodified release then my modified version of Zebar), I change the Komorebi version here and I get the following result:
v0.1.22 works with the stackbar with Zebar v1.3 (unmodified)

v0.1.23 and v0.1.24 do not work with the stackbar with Zebar v1.3 (unmodified)

v0.1.22 works with the stackbar with Zebar v1.3 (modified by me)

v0.1.23 does not work with the stackbar with Zebar v1.3 (modified by me)

I hope this helps in hunting down this bug
@CtByte commented on GitHub (Apr 15, 2024):
oh and I saw the stackbar flash in for a second, then disappear when using Komorebi v0.1.23
@LGUG2Z commented on GitHub (Apr 16, 2024):
I was able to repro this not with zebar but with another Rust GUI app 🤔
@LGUG2Z commented on GitHub (Apr 16, 2024):
The stackbars will reappear if sending a message to change the stackbar mode from Never to Always/OnStack via
komorebi-eguion the feature/egui branch (requireskomorebito be installed from the same commit), so it looks like the stackbar is salvagable after one of these events, just need to dig to try and avoid this happening in the first place. cc @raggi@LGUG2Z commented on GitHub (Apr 16, 2024):
@CtByte not sure if you're able to build locally, but if you can, would you try building komorebi/komorebic/komorebi-egui from the feature/egui branch and then toggling the stackbar mode to Never and then to Always or OnStack after you have launched zebar and the stackbars initially disappear?
@CtByte commented on GitHub (Apr 16, 2024):
@LGUG2Z I will try my best to help you out. I have a few busy days ahead so it might take some time before I could get back to you with some results (I might have some questions regarding that).
I appreciate all the effort going into hunting this bug down :)
@raggi commented on GitHub (Apr 16, 2024):
I'm not quite sure what's causing the hiding behavior/haven't had a chance to repro this yet. I can hopefully take a look after work tonight.
Some thoughts in the meantime:
So in slightly simpler terms, the stackbar should regularly update itself on foreground window changes/stack changes to:
let stack_top_hwnd = self.my_stack.current_top_hwnd();
SetWindowPos(stackbar_hwnd, stack_top_hwnd, x, y, cx, cy, SWP_NOACTIVATE);
This is similar to, but slightly different from the border window: The border window regularly raises itself to HWND_TOP, except it also hides itself when a non-managed window is made foreground_window, which is what prevents it from drawing over other windows (as there's only one). If we later make a border window per managed window (something we're talking about) then the rules get more fancy, where it would need to find the window it's wrapping and always position itself exaclty above that window in the z-order (not top, not topmost, etc).
Note that something like
self.my_stack.current_top_hwnd()might be slightly painful to add right now. I suspect we can approximate this behavior quickly by instead setting ourselves to just underneath the foreground window all the time (WindowsApi::foreground_window()) - this would be imperfect, if you have two floating windows, one recently foreground, one now foreground, the stackbar would draw over the top of the recently foreground floating window - messy & not ideal, but still usable as a first step.@LGUG2Z commented on GitHub (Apr 17, 2024):
More data points:
@CtByte commented on GitHub (Apr 17, 2024):
@LGUG2Z I tried to run komorebi from the
feature/eguibranch. I managed kinda, but I would like to detail what I did, as I started learning Rust 2-3 weeks ago ( thanks to you :D ) and I want to make sure I am doing the right thing.cargo buildcommandkomorebi.execommandkomorebic.exe start --whkdcommand in a new consoleHere is the result:
stackbar mode=OnStackstackbar mode=Neverstackbar mode=AlwaysClicking on the stackbar also worked, it changed the window.
The next step was to run the komorebi-egui.
When I ran the ...\LGUG2Z\komorebi\target\debug>
.\komorebi-egui.execommand I got this error (not sure how to run withRUST_BACKTRACE=1):I tried to add the setting as stated here, but it gave a new error (new line number)
I am probably doing something wrong, could you please let me know what?
@CtByte commented on GitHub (Apr 17, 2024):
One thing I did wrong is that I did not stop Zebar before tests....sorry about that. But now I know that if Komorebi is started after Zebar then the stackbar works.
So, what I also did was:
.\komorebi.execommand.\komorebic.exe start --whkdcommand in a new consoleWhat I think you find more useful is that in each mode (Never,OnStack,Always) the stackbar disappeared and when I clicked on a window, this warning came in the console:
I hope this is more useful, and if you want me to do more tests, please let me know (also if I missed something).
Can this be a Zebar related issue?
@CtByte commented on GitHub (Apr 17, 2024):
An other thing I noticed is that the Komorebi provider in Zebar is not working when I run it from the
feature/eguibranch, but it still works for me when I run "my modified" Zebar with Komorebi v0.1.24. Others have problem with the latest Komorebi version after updating.@LGUG2Z commented on GitHub (Apr 18, 2024):
@CtByte it looks like you're running
komorebic startwhich will look for thekomorebi.exein your$Env:PATHand not in thetarget/debugfolder. The best way around this is to run thecargo installcommand instead of thecargo buildcommand, and usually this will put the binary in an output folder that is both in the PATH and one that has a higher priority than other installed binaries with the same name.@CtByte commented on GitHub (Apr 18, 2024):
@LGUG2Z Thank you, that makes sense, I managed to use install from here
c:\Users\<username>\.cargo\bin\toc:\Program Files\komorebi\bin\where my$Env:PATHpointed to for good measure....\LGUG2Z\komorebi\target\debug>WARNing and the Komorebi provider of Zebar does not show up, but that is for another time)I hope that this is what you asked me to do.
@CtByte commented on GitHub (Apr 24, 2024):
@LGUG2Z I have a small update on this, I hope this helps. It seems that the stackbar only disappears when I use the Komorebi provider in Zebar.
I started Komorebi, stacked a few windows like before, started Zebar without using the Komorebi provider, and the stackbar did not disappear.
I am using Komorebi v0.1.24. If you need me to test more, please let me know.
@CtByte commented on GitHub (Apr 24, 2024):
Could there be an error when Zebar connects to Komorebi via the socket connection?
@LGUG2Z commented on GitHub (Apr 29, 2024):
Another way to reproduce this issue here: https://github.com/LGUG2Z/komorebi/issues/792
I've pinned this issue to give it a bit more visibility on the tracker and hopefully attract people with new ideas about how to fix this bug.
@LGUG2Z commented on GitHub (Apr 29, 2024):
@tgrosinger I believe 611fa34 fixes the stackbar disappearing with reloads 🎉
It turns out that the stackbar windows are disappearing because of actions in various code paths that result in
Dropbeing called. To make these a little easier to track down I've added a debug log whenever a stackbar window is being dropped:https://github.com/LGUG2Z/komorebi/blob/611fa3456703e8804ab708831694425894ad79f7/komorebi/src/stackbar.rs#L77
@CtByte I don't have Zebar set up myself, but maybe you can see if this makes any difference for you?
@LGUG2Z commented on GitHub (Apr 30, 2024):
@CtByte 7cab062 should be the fix for Zebar as well!
cc @lars-berger 🎉
@CtByte commented on GitHub (Apr 30, 2024):
@LGUG2Z Thank you so much for looking into this! I will validate the fix with Zebar very soon, so we can close this issue.
@CtByte commented on GitHub (Apr 30, 2024):
@LGUG2Z I tried both ways to reproduce this issue (Zebar and #792)
I can verify that the issue with the config reloading is solved.
I had to add the new layout (RightMainVerticalStack) to Zebar and ran it on this rev
komorebi-client = { git = "https://github.com/LGUG2Z/komorebi", rev = "871a53821c3bc7866f479132d060fe8a8e902c21" }The issue with the stackbar is solved 🎉
The only problem is that Zebar needs to be changed for the fix to take affect.

So if the
Cargo.tomlis using the newest rev and thekomorebi\variables.rsis updated then it should work.I can wait making the pull request until perhaps the next release of Komorebi, so then not the rev, but the tag would be used.
What do you think? Can this issue be closed now or I should wait until Zebar is updated?
@LGUG2Z commented on GitHub (Apr 30, 2024):
I'm going to cut a release for v0.1.25 now so that it can be tagged in the PR to Zebar 🤞
@LGUG2Z commented on GitHub (May 1, 2024):
https://github.com/LGUG2Z/komorebi/releases/tag/v0.1.25
@CtByte commented on GitHub (May 1, 2024):
@LGUG2Z Thank you very much for your help!
I did what I can for Zebar