[BUG]: stackbar disappears #331

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

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 and start it using the bat file
  4. See bug

Expected behavior
The stackbar does not disappear.

Screenshots of the bug before and after Zebar is started
Screenshot 2024-04-13 170841
Screenshot 2024-04-13 170938

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
adam closed this issue 2026-01-05 14:49:47 +01:00
Author
Owner

@LGUG2Z commented on GitHub (Apr 13, 2024):

It's likely an issue with komorebi. Does the stackbar reappear if you unstack and then restack?

@LGUG2Z commented on GitHub (Apr 13, 2024): It's likely an issue with komorebi. Does the stackbar reappear if you unstack and then restack?
Author
Owner

@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

@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
Author
Owner

@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 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.
Author
Owner

@CtByte commented on GitHub (Apr 13, 2024):

@LGUG2Z
It was not easy to install, but I gave it a try.

Screenshot 2024-04-13 200112

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.
Author
Owner

@LGUG2Z commented on GitHub (Apr 15, 2024):

@lars-berger any ideas? 👀

@LGUG2Z commented on GitHub (Apr 15, 2024): @lars-berger any ideas? 👀
Author
Owner

@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): Can it be confirmed that this is not just me? I would feel much better :)
Author
Owner

@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)
Screenshot 2024-04-15 212811 v0 1 22

v0.1.23 and v0.1.24 do not work with the stackbar with Zebar v1.3 (unmodified)
Screenshot 2024-04-15 213357

Screenshot 2024-04-15 213510

v0.1.22 works with the stackbar with Zebar v1.3 (modified by me)
Screenshot 2024-04-15 213951

v0.1.23 does not work with the stackbar with Zebar v1.3 (modified by me)
Screenshot 2024-04-15 214037

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
Author
Owner

@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

@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
Author
Owner

@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): I was able to repro this not with zebar but with another Rust GUI app 🤔
Author
Owner

@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

@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
Author
Owner

@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?

image

@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? ![image](https://github.com/LGUG2Z/komorebi/assets/13164844/626df05b-8d62-4c06-b5d3-90bf1bfc854d)
Author
Owner

@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 :)

@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 :)
Author
Owner

@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.

@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.
Author
Owner

@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 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
Author
Owner

@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

Screenshot 2024-04-17 181924

stackbar mode=Never

Screenshot 2024-04-17 182307

stackbar mode=Always

Screenshot 2024-04-17 182607

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)

Screenshot 2024-04-17 184446
...\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?
Author
Owner

@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?

@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?
Author
Owner

@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 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.
Author
Owner

@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.

@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.
Author
Owner

@CtByte commented on GitHub (Apr 18, 2024):

@LGUG2Z Thank you, that makes sense, I managed to use install from here

  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
  1. 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.
  2. Then I ran these commands in ...\LGUG2Z\komorebi\target\debug>
.\komorebi.exe
.\komorebic.exe start --whkd
.\komorebi-egui.exe
  1. Now I have the gui as well
  2. I start Zebar and any stackbars I had, disappeared
  3. As you can see in the logs, I clicked the never/onstack/always options for the stackbar in the egui
  4. The stackbars appear again when I am clicking.
  5. (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.
Author
Owner

@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): @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.
Author
Owner

@CtByte commented on GitHub (Apr 24, 2024):

Could there be an error when Zebar connects to Komorebi via the socket connection?

@CtByte commented on GitHub (Apr 24, 2024): Could there be an error when Zebar connects to Komorebi via the socket connection?
Author
Owner

@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): 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.
Author
Owner

@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 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:

611fa34567/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 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?
Author
Owner

@LGUG2Z commented on GitHub (Apr 30, 2024):

@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 🎉
Author
Owner

@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 Thank you so much for looking into this! I will validate the fix with Zebar very soon, so we can close this issue.
Author
Owner

@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.
Screenshot 2024-04-30 200617

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?
Author
Owner

@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 (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 🤞
Author
Owner

@LGUG2Z commented on GitHub (May 1, 2024):

https://github.com/LGUG2Z/komorebi/releases/tag/v0.1.25

@LGUG2Z commented on GitHub (May 1, 2024): https://github.com/LGUG2Z/komorebi/releases/tag/v0.1.25
Author
Owner

@CtByte commented on GitHub (May 1, 2024):

@LGUG2Z Thank you very much for your help!

I did what I can for Zebar

@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)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#331