starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

[PR #1146] [MERGED] fix(wm): resize float windows moved across monitors #1224

New Issue
Closed
opened 2026-01-05 14:54:31 +01:00 by adam · 0 comments
adam commented 2026-01-05 14:54:31 +01:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/LGUG2Z/komorebi/pull/1146
Author: @alex-ds13
Created: 11/25/2024
Status: ✅ Merged
Merged: 11/26/2024
Merged by: @LGUG2Z

Base: master ← Head: fix/resize-float-windows-across-monitors

📝 Commits (1)

  • 053360f fix(wm): resize float windows moved across monitors

📊 Changes

1 file changed (+9 additions, -6 deletions)

View changed files

📝 komorebi/src/window.rs (+9 -6)

📄 Description

Previously when moving floating windows across monitors we would keep the size of the window as it was. For most cases this would be ok. However for users with monitors with completely different sizes this could result on a window that would fill across monitors when moving from the bigger monitor to the smaller monitor.

This commit, attempts to resize the windows proportionally to the monitors' sizes.

There is currently a slight issue with some apps (so far I've only noticed it on 'Wezterm'...) where if the DPIs across monitors are different they don't seem to fully get the Windows OS DPI change completely applied, but it seems that setting the Wezterm compatibility high DPI scaling override to "System" on the app's executable properties, fixes the issue. Since this is only 1 app (so far...) and only when the scales between monitors are different I decided to commit this anyway.

Since in the cases it was misbehaving with 'Wezterm' the result would be a wrongly resized window that is still completely visible on the target monitor anyway and the override fix seems to be good so far, I think we can merge nonetheless.

This fixes an issue brought up by a user on Discord.

For anyone visiting this PR in the future the override setting I'm talking about is from this screen:
image

Where instead of "Application" you should set it to "System". This should only be necessary if you notice that after moving a floating window across monitors with different sizes/DPIs the window moves and appears to do another resize that makes it bigger than the monitor you are trying to move to. So far I've only noticed this on Wezterm...

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/LGUG2Z/komorebi/pull/1146 **Author:** [@alex-ds13](https://github.com/alex-ds13) **Created:** 11/25/2024 **Status:** ✅ Merged **Merged:** 11/26/2024 **Merged by:** [@LGUG2Z](https://github.com/LGUG2Z) **Base:** `master` ← **Head:** `fix/resize-float-windows-across-monitors` --- ### 📝 Commits (1) - [`053360f`](https://github.com/LGUG2Z/komorebi/commit/053360f252e1512eb16adae1555d918a104688be) fix(wm): resize float windows moved across monitors ### 📊 Changes **1 file changed** (+9 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `komorebi/src/window.rs` (+9 -6) </details> ### 📄 Description Previously when moving floating windows across monitors we would keep the size of the window as it was. For most cases this would be ok. However for users with monitors with completely different sizes this could result on a window that would fill across monitors when moving from the bigger monitor to the smaller monitor. This commit, attempts to resize the windows proportionally to the monitors' sizes. There is currently a slight issue with some apps (so far I've only noticed it on 'Wezterm'...) where if the DPIs across monitors are different they don't seem to fully get the Windows OS DPI change completely applied, but it seems that setting the `Wezterm` compatibility high DPI scaling override to "System" on the app's executable properties, fixes the issue. Since this is only 1 app (so far...) and only when the scales between monitors are different I decided to commit this anyway. Since in the cases it was misbehaving with 'Wezterm' the result would be a wrongly resized window that is still completely visible on the target monitor anyway and the override fix seems to be good so far, I think we can merge nonetheless. This fixes an issue brought up by a user on [Discord][1]. For anyone visiting this PR in the future the override setting I'm talking about is from this screen: ![image](https://github.com/user-attachments/assets/730fd445-8143-4e38-96e1-b6e5ecccdd4e) Where instead of "Application" you should set it to "System". This should only be necessary if you notice that after moving a floating window across monitors with different sizes/DPIs the window moves and appears to do another resize that makes it bigger than the monitor you are trying to move to. So far I've only noticed this on Wezterm... [1]: https://discord.com/channels/898554690126630914/1309289140482998282 <!-- Please follow the Conventional Commits specification. If you need to update your PR with changes from `master`, please run `git rebase master`. By opening this PR, you confirm that you have read and understood this project's `CONTRIBUTING.md`. --> --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2026-01-05 14:54:31 +01:00
adam closed this issue 2026-01-05 14:54:31 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#1224
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?