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

[BUG]: Window size imprecise #258

New Issue
Closed
opened 2026-01-05 14:49:19 +01:00 by adam · 7 comments
adam commented 2026-01-05 14:49:19 +01:00
Owner
Copy Link

Originally created by @mangkoran on GitHub (Nov 1, 2023).

Describe the bug
Several applications have imprecise window size. So far I found WezTerm and Discord.

To Reproduce
Steps to reproduce the behavior:

  1. Install WezTerm and Discord
  2. Run komorebi with default setting (from Quickstart) with the following
  "default_workspace_padding": 5,
  "default_container_padding": 5,

Expected behavior
Precise window size

Screenshots and Videos
WezTerm - Notepad++ (Notepad++ is fine)
image

Chrome - Discord (really small/fine but it's there)
image
image

Operating System
Provide the output of systeminfo | grep "^OS Name\|^OS Version"

OS Name:                   Microsoft Windows 10 IoT Enterprise LTSC
OS Version:                10.0.19044 N/A Build 19044

komorebic check Output
Provide the output of komorebic check

No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\mangkoran

Looking for configuration files in C:\Users\mangkoran

No komorebi configuration found in C:\Users\mangkoran

If running 'komorebic start --await-configuration', you will manually have to call the following command to begin tiling: komorebic complete-configuration

Additional context
None

Originally created by @mangkoran on GitHub (Nov 1, 2023). **Describe the bug** Several applications have imprecise window size. So far I found WezTerm and Discord. **To Reproduce** Steps to reproduce the behavior: 1. Install WezTerm and Discord 2. Run komorebi with default setting (from Quickstart) with the following ``` "default_workspace_padding": 5, "default_container_padding": 5, ``` **Expected behavior** Precise window size **Screenshots and Videos** WezTerm - Notepad++ (Notepad++ is fine) ![image](https://github.com/LGUG2Z/komorebi/assets/57625126/9a70d76a-375f-4164-b806-aeffead4b646) Chrome - Discord (really small/fine but it's there) ![image](https://github.com/LGUG2Z/komorebi/assets/57625126/12d95626-5d47-403a-a2e2-48adf47989b3) ![image](https://github.com/LGUG2Z/komorebi/assets/57625126/5390c60a-61df-4a2c-9a29-4fdf7a98a88c) **Operating System** Provide the output of `systeminfo | grep "^OS Name\|^OS Version"` ``` OS Name: Microsoft Windows 10 IoT Enterprise LTSC OS Version: 10.0.19044 N/A Build 19044 ``` **`komorebic check` Output** Provide the output of `komorebic check` ``` No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\mangkoran Looking for configuration files in C:\Users\mangkoran No komorebi configuration found in C:\Users\mangkoran If running 'komorebic start --await-configuration', you will manually have to call the following command to begin tiling: komorebic complete-configuration ``` **Additional context** None
adam added the bug label 2026-01-05 14:49:19 +01:00
adam closed this issue 2026-01-05 14:49:19 +01:00
adam commented 2026-01-05 14:49:19 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Nov 1, 2023):

I'm not sure that there is much that can be done here as these applications seem to be reporting their window and border dimensions incorrectly to the operating system.

In theory we could provide another per-window override configured by the user to target applications like this on a case by case basis, but it would be better for everyone if these issues could be fixed in the applications themselves rather than being targeted by overrides in a window manager.

I'll leave this ticket open if people want to brainstorm, but I suggest opening issues on the repos of the relevant applications and referencing back to this issue.

@LGUG2Z commented on GitHub (Nov 1, 2023): I'm not sure that there is much that can be done here as these applications seem to be reporting their window and border dimensions incorrectly to the operating system. In theory we could provide another per-window override configured by the user to target applications like this on a case by case basis, but it would be better for everyone if these issues could be fixed in the applications themselves rather than being targeted by overrides in a window manager. I'll leave this ticket open if people want to brainstorm, but I suggest opening issues on the repos of the relevant applications and referencing back to this issue.
adam commented 2026-01-05 14:49:19 +01:00
Author
Owner
Copy Link

@mangkoran commented on GitHub (Nov 3, 2023):

Thank you for your reply.

Hmm if it's due to the affected application, then it is surely will be a long, hard work 😅

I wonder, Microsoft's PowerToys has a feature called FancyZones that can "tile"/resize windows (although it's not a tiling WM like komorebi). I am using FZ daily, and with FZ it can tile almost (if not all) windows/apps perfectly. Well it is might be due to different implementation, but I wonder why FZ can tile more perfectly?

WezTerm - Notepad++ (both using FZ)
image

@mangkoran commented on GitHub (Nov 3, 2023): Thank you for your reply. Hmm if it's due to the affected application, then it is surely will be a long, hard work 😅 I wonder, Microsoft's PowerToys has a feature called [FancyZones](https://learn.microsoft.com/en-us/windows/powertoys/fancyzones) that can "tile"/resize windows (although it's not a tiling WM like komorebi). I am using FZ daily, and with FZ it can tile almost (if not all) windows/apps perfectly. Well it is might be due to different implementation, but I wonder why FZ can tile more perfectly? WezTerm - Notepad++ (both using FZ) ![image](https://github.com/LGUG2Z/komorebi/assets/57625126/b70d5e9c-ce63-42eb-877a-e4e092f092a8)
adam commented 2026-01-05 14:49:19 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Nov 3, 2023):

I've tried to reproduce your first example on Windows 11, with significant overlapping of the windows of WezTerm and Notepad++ by using exaggerated negative container padding, but I haven't been able to reproduce the height difference shown on your first screenshot.

This is the only instance in the codebase where an override may be applied to window size calculation; it is explicitly opt-in and it applies overrides to all four sides of the Rect rather than any one side: https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/window.rs#L151

Otherwise, all of the window size calculations are made indiscriminately on plain Rect objects with no information about the applications that they will be applied to; there isn't really a way that I can see that heights would be calculated different for specific applications regardless of their positions: https://github.com/LGUG2Z/komorebi/blob/master/komorebi-core/src/arrangement.rs#L28

I'm not very familiar with the PowerToys/FancyZones codebase, but if someone is, and the replication of what they are doing to overcome these height differences does not require significant changes to the layout/arrangement code, I'm happy to accept a PR here.

For future users who notice this, can you please specify here if you are running Win10 or Win11? It would be good to get some more data to determine if this impacts both Win10+11, or just Win10. 🙏

@LGUG2Z commented on GitHub (Nov 3, 2023): I've tried to reproduce your first example on Windows 11, with significant overlapping of the windows of WezTerm and Notepad++ by using exaggerated negative container padding, but I haven't been able to reproduce the height difference shown on your first screenshot. This is the only instance in the codebase where an override may be applied to window size calculation; it is explicitly opt-in and it applies overrides to all four sides of the `Rect` rather than any one side: https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/window.rs#L151 Otherwise, all of the window size calculations are made indiscriminately on plain `Rect` objects with no information about the applications that they will be applied to; there isn't really a way that I can see that heights would be calculated different for specific applications regardless of their positions: https://github.com/LGUG2Z/komorebi/blob/master/komorebi-core/src/arrangement.rs#L28 I'm not very familiar with the PowerToys/FancyZones codebase, but if someone is, and the replication of what they are doing to overcome these height differences does not require significant changes to the layout/arrangement code, I'm happy to accept a PR here. For future users who notice this, can you please specify here if you are running Win10 or Win11? It would be good to get some more data to determine if this impacts both Win10+11, or just Win10. 🙏
adam commented 2026-01-05 14:49:19 +01:00
Author
Owner
Copy Link

@Zinvoke commented on GitHub (Nov 14, 2023):

This actually is a problem in GlazeWM and Komorebi if you try out FancyWM you will see that the issue doesn't exist for any applications even if applications are reporting wrong sizes. Lars thought this might be the correct way of doing things 67519f111a/src/WinMan.Windows/Windows/Win32Window.cs (L606)

@Zinvoke commented on GitHub (Nov 14, 2023): This actually is a problem in GlazeWM and Komorebi if you try out FancyWM you will see that the issue doesn't exist for any applications even if applications are reporting wrong sizes. Lars thought this might be the correct way of doing things https://github.com/FancyWM/winman-windows/blob/67519f111af808aa29627ca715968b0ce86885b8/src/WinMan.Windows/Windows/Win32Window.cs#L606
adam commented 2026-01-05 14:49:20 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Nov 15, 2023):

Hmm @Zinvoke if we get the frame margins does that mean that we don't need to remove the invisible borders anymore? 🤔

@LGUG2Z commented on GitHub (Nov 15, 2023): Hmm @Zinvoke if we get the frame margins does that mean that we don't need to remove the invisible borders anymore? 🤔
adam commented 2026-01-05 14:49:20 +01:00
Author
Owner
Copy Link

@Zinvoke commented on GitHub (Nov 16, 2023):

Hmm @Zinvoke if we get the frame margins does that mean that we don't need to remove the invisible borders anymore? 🤔

No idea but somehow FancyWM pulls it off :(
if you look at these screenshots you can see that the 2 outside windows when using komorebi are both different sizes then the middle window and when using FancyWM all of the windows are the same size!

Komorebi Screenshot:
PrMlLLwNih

FancyWM Screenshot:
V0QmVr5OIB

Note: In the screenshots the border colors are changed via a program I made called FancyBorders using the DWMWA_BORDER_COLOR flag which allows you to see the actual border sizes better and the programs are Explorer, Vscode, Windows Terminal, Discord

@Zinvoke commented on GitHub (Nov 16, 2023): > Hmm @Zinvoke if we get the frame margins does that mean that we don't need to remove the invisible borders anymore? 🤔 No idea but somehow FancyWM pulls it off :( if you look at these screenshots you can see that the 2 outside windows when using komorebi are both different sizes then the middle window and when using FancyWM all of the windows are the same size! Komorebi Screenshot: ![PrMlLLwNih](https://github.com/LGUG2Z/komorebi/assets/84819317/6289f07c-767d-4072-b2be-86221bfbfec4) FancyWM Screenshot: ![V0QmVr5OIB](https://github.com/LGUG2Z/komorebi/assets/84819317/61cd9e5b-3107-497e-b884-608e0bd9d997) **Note:** In the screenshots the border colors are changed via a program I made called FancyBorders using the DWMWA_BORDER_COLOR flag which allows you to see the actual border sizes better and the programs are Explorer, Vscode, Windows Terminal, Discord
adam commented 2026-01-05 14:49:20 +01:00
Author
Owner
Copy Link

@xidsyed commented on GitHub (Sep 1, 2024):

This actually is a problem in GlazeWM and Komorebi if you try out FancyWM you will see that the issue doesn't exist for any applications even if applications are reporting wrong sizes. Lars thought this might be the correct way of doing things 67519f111a/src/WinMan.Windows/Windows/Win32Window.cs (L606)

Sorry this is a bit late, but and unrelated, but how have you found the experience of using FanzyWM. What features does it lack compared to komorebi

@xidsyed commented on GitHub (Sep 1, 2024): > This actually is a problem in GlazeWM and Komorebi if you try out FancyWM you will see that the issue doesn't exist for any applications even if applications are reporting wrong sizes. Lars thought this might be the correct way of doing things https://github.com/FancyWM/winman-windows/blob/67519f111af808aa29627ca715968b0ce86885b8/src/WinMan.Windows/Windows/Win32Window.cs#L606 Sorry this is a bit late, but and unrelated, but how have you found the experience of using FanzyWM. What features does it lack compared to komorebi
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 bug
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#258
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?