[BUG]: stackbar disappears

[CtByte]

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

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!

[LGUG2Z]

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

[CtByte]

@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

[LGUG2Z]

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]

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

@lars-berger any ideas? 👀

[CtByte]

Can it be confirmed that this is not just me? I would feel much better :)

[CtByte]

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

oh and I saw the stackbar flash in for a second, then disappear when using Komorebi v0.1.23

[LGUG2Z]

I was able to repro this not with zebar but with another Rust GUI app 🤔

[LGUG2Z]

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]

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

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

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.

[LGUG2Z]

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

[CtByte]

@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

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]

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]

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.

[LGUG2Z]

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

[CtByte]

@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

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 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]

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

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

[LGUG2Z]

Another way to reproduce this issue here: #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]

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

komorebi/komorebi/src/stackbar.rs

Line 77 in 611fa34

tracing::debug!("dropping and calling close_window on stackbar");

@CtByte I don't have Zebar set up myself, but maybe you can see if this makes any difference for you?

[LGUG2Z]

@CtByte 7cab062 should be the fix for Zebar as well!

cc @lars-berger 🎉

[CtByte]

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

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

[LGUG2Z]

I'm going to cut a release for v0.1.25 now so that it can be tagged in the PR to Zebar 🤞

[LGUG2Z]

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

[CtByte]

@LGUG2Z Thank you very much for your help!

I did what I can for Zebar