mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
[BUG]: stackbar disappears #331
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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: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 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