-
-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG]: Stacked windows are not moved together using komorebic move
commands
#832
Comments
I'm not able to reproduce this exactly but I do have some jank when using the mouse instead of the hotkeys. Since the hotkeys work for now I'm gonna leave this open until I can split out the stackbar into its own module like I did for the borders and see if this is one of the those edge cases that gets fixed by the more isolated design 🤞 |
I could not always reproduce this exactly either, but let's see what comes up when you get the time to make the stackbar module 🤞 |
I am running the I have the feeling that the stackbar used to hide stacked windows that were not visible (behind the focused tab). Almost like when you change between workspaces. |
I think this is fixed on the stackbar manager branch now 🤞 |
I tried out the Once I click the tabs it behaves differently, similar to what I described as hidden stacked windows being stuck and the stack being scattered around 2 monitors. I am also getting this error in the console when I am clicking the tabs (after moving the stack to another monitor): (not sure how much of the logs I should grab)
And when I use the hotkey So I am guessing there is something done differently when the command is used and when the mouse is used. |
I tried reproducing both of the issues you described after making some changes in the commit above and everything looks okay to me now; no cross-monitor move errors or rendering of windows in old positions on my end 🤞 |
I tried to test it in every possible way I could think of and it worked. 🎉 I moved the stack and clicked the tabs with mouse only, command only and a mix of the two. The only thing I could not do is moving the stack by mouse on the same monitor to swap places with another window. When I move a none stacked window to swap places with a stack that worked. Recording.2024-05-19.161735.mp4It can be that I am just clumsy, but I would consider this to be a win. Thank you for taking the time! |
Mouse moving has also been fixed here: b68ba2f |
I confirm, indeed it is 👍 |
This commit removes all stackbar-related code from Container, Workspace, process_command, process_event etc. and centralizes it in the new stackbar_manager module. Instead of trying to figure out where in process_event and process_command we should make stackbar-related changes, a notification gets sent to a channel that stackbar_manager listens to whenever an event or command has finished processing. The stackbar_manager listener, upon receiving a notification, acquires a lock on the WindowManager instance and updates stackbars for the focused workspace on every monitor; this allows us to centralize all edge case handling within the stackbar_manager listener's loop. Global state related to stackbars has also been moved into the stackbar_manager module, which also tracks the state of stackbar objects (STACKBAR_STATE), mappings between stackbars and containers (STACKBARS_CONTAINERS) and the mappings between stackbars and monitors (STACKBARS_MONITORS). A number of edge cases around stackbar behaviour have been addressed in this commit (re #832), and stackbars now respect the "border_style" configuration option.
This commit removes all stackbar-related code from Container, Workspace, process_command, process_event etc. and centralizes it in the new stackbar_manager module. Instead of trying to figure out where in process_event and process_command we should make stackbar-related changes, a notification gets sent to a channel that stackbar_manager listens to whenever an event or command has finished processing. The stackbar_manager listener, upon receiving a notification, acquires a lock on the WindowManager instance and updates stackbars for the focused workspace on every monitor; this allows us to centralize all edge case handling within the stackbar_manager listener's loop. Global state related to stackbars has also been moved into the stackbar_manager module, which also tracks the state of stackbar objects (STACKBAR_STATE), mappings between stackbars and containers (STACKBARS_CONTAINERS) and the mappings between stackbars and monitors (STACKBARS_MONITORS). A number of edge cases around stackbar behaviour have been addressed in this commit (re #832), and stackbars now respect the "border_style" configuration option.
Describe the bug
When stacked windows are moved using the commands, only the top window is moved. The behaviour is slightly different when moving on the same monitor or when moving to an other monitor.
I am using the UltrawideVerticalStack layout.
To Reproduce
Steps to reproduce the behavior (see video):
Monitor 1 b
,Monitor 1 a
,Firefox
komorebic move right
command.Monitor 1 a
stuck on the left.Firefox
,Monitor 1 a
,Monitor 1 b
Monitor 1 a
.Monitor 1 a
jumps to the left.Firefox
,Monitor 1 b
,Monitor 1 a
In case moving to an other monitor, the "stuck" window will not jump under the stackbar when clicking on its tag. An other window (that is not in the stack,
Firefox
in my example) needs to be focused for that to happen.But even this does not always work, so it can be tested again if this can be fixed for a single monitor.
Expected behavior
Stacked windows are moved together.
Videos
Recording.2024-05-17.201515.mp4
Operating System
komorebic check
OutputAdditional context
When I switch to another workplace and back at
step 4
(instead of clicking the tab), the "stuck" window jumps to the correct position like instep 6
. The same seems to be true when I change the workspace (where the "stuck" window is) on the multi monitor test.The text was updated successfully, but these errors were encountered: