-
-
Notifications
You must be signed in to change notification settings - Fork 205
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix(wm): cross-monitor ops for floating windows
This commit fixes an issue where when trying to move floating windows or windows on a floating workspace across boundaries to another monitor using the `move_container_in_direction` it wouldn't move the floating windows physically, although it moved them internally on komorebi, resulting in weird and wrong behavior. This commit creates a new method on `Monitor` to `add_container_with_direction` which takes a move direction and then uses the same logic that was previously on the `move_container_in_direction` function. It changes the `move_container_to_monitor` function to take an optional move direction which if it is some will have this function call the new method `add_container_with_direction` instead of just `add_container`. Lastly the `move_container_in_direction` function now when it realizes the move will be across monitors simply calls the `move_container_to_monitor` with the direction that was initially given to it. These changes require that all callers of `move_container_to_monitor` add an direction option, instead of passing `None` on all of them, a new helper function was created, named `direction_from_monitor_idx` which calculates the direction a move will have from the currently focused monitor and the target monitor return `None` if they are the same or returning `Some(direction)` if not. This way now all commands that call a move across monitor will use the logic to check from the direction if it should add the container on front or end. With these changes now all the code related to moving a window across monitors using a command should be on one place only making sure that in the future any change required only needs to be done on one place, instead of having to do it on `move_container_to_monitor` and `move_container_in_direction` as before! This commit is an interactive squashed rebase of the following commits from PR #1154: 8f4bc10 fix(wm): move floats in direction across monitors This commit fixes an issue where when trying to move floating windows or windows on a floating workspace across boundaries to another monitor using the `move_container_in_direction` it wouldn't move the floating windows physically, although it moved them internally on komorebi, resulting in weird and wrong behavior. This commit creates a new method on `Monitor` to `add_container_with_direction` which takes a move direction and then uses the same logic that was previously on the `move_container_in_direction` function. It changes the `move_container_to_monitor` function to take an optional move direction which if it is some will have this function call the new method `add_container_with_direction` instead of just `add_container`. Lastly the `move_container_in_direction` function now when it realizes the move will be across monitors simply calls the `move_container_to_monitor` with the direction that was initially given to it. These changes require that all callers of `move_container_to_monitor` add an direction option, instead of passing `None` on all of them, a new helper function was created, named `direction_from_monitor_idx` which calculates the direction a move will have from the currently focused monitor and the target monitor return `None` if they are the same or returning `Some(direction)` if not. This way now all commands that call a move across monitor will use the logic to check from the direction if it should add the container on front or end. 3b20e4b refactor(wm): use helper function on move to workspace Use the same `add_container_with_direction` function on `move_container_to_workspace` as it is being used on `move_container_to_monitor` or `move_container_in_direction`. This way we bring parity between all methods and make it easier to change the way a container is added on a monitor workspace when taking the move direction into consideration.
- Loading branch information
Showing
3 changed files
with
161 additions
and
138 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters