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 #678] [MERGED] Simpler and more precise border production #1051

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

📋 Pull Request Information

Original PR: https://github.com/LGUG2Z/komorebi/pull/678
Author: @raggi
Created: 2/20/2024
Status: ✅ Merged
Merged: 2/26/2024
Merged by: @LGUG2Z

Base: master ← Head: raggi/borders

📝 Commits (9)

  • ba52f1a komorebi{,-core}: use window bounds without shadow
  • 3b8bc0c fix(cfg,komorebi): remove all uses of invisible borders
  • 9d07938 fix(komorebi): restore borders, no more DWM border on border window
  • c87cf61 fix(komorebi): account for border offset and width in layout
  • 1469d0f fix(komorebi): account for border decorations on resize
  • ad4a899 fix(config): set new default border offset and width
  • 6b24827 fix(komorebi): raise windows and border to top, not topmost
  • 6e95084 fix(komorebi): close the corner gap around rounded corners
  • dc88ea4 fix(komorebi): don't raise the border window to top

📊 Changes

14 files changed (+163 additions, -229 deletions)

View changed files

📝 komorebi-core/src/arrangement.rs (+2 -2)
📝 komorebi-core/src/rect.rs (+24 -7)
📝 komorebi/src/border.rs (+4 -44)
📝 komorebi/src/lib.rs (+1 -2)
📝 komorebi/src/monitor.rs (+1 -2)
📝 komorebi/src/process_command.rs (+6 -23)
📝 komorebi/src/process_event.rs (+5 -20)
📝 komorebi/src/static_config.rs (+4 -42)
📝 komorebi/src/window.rs (+2 -29)
📝 komorebi/src/window_manager.rs (+14 -38)
📝 komorebi/src/windows_api.rs (+62 -11)
📝 komorebi/src/windows_callbacks.rs (+15 -2)
📝 komorebi/src/workspace.rs (+21 -5)
📝 schema.json (+2 -2)

📄 Description

This includes three changes that could be included independently though each has some side effect that is adjusted by the latter to better align with the overall goal.

I set out to remove the inconsistent gap and miscoloration around windows. This was originating in the interactions with DWM decorations.

First the API that we're using to read window size is shifted to one that returns Window dimensions without including the DWM/theme decorations.

Next in order to fix a number of new regressions vs. the application database, we needed to remove the use of the invisible borders - these were a side effect of the DWM decorations. They're no longer needed, as application Window dimensions are now correct, with one notable interaction with theming (below).

Finally we move away from allowing/using DWM decorations on the border window. While this was giving us a rounded corner, it was causing offset bugs due to the fact that the theme is not symmetrical. This was making it impossible to draw very thin borders correctly, for example few pixel borders.

There is one final caveat noted here, the problem exists already in a different form, but for the same as yet unresolved reasons. Single pixel borders work correctly with this setup but there remain overlapping concerns with the system them. The windows DWM theme adds an active window border as well, and how opaque this border is depends upon the theme (this is present even if the drop shadow is off). That border often produces what appears to be a single semi-transparent pixel border around the window that looks like a "gap" in many scenarios. Most users will want to set border-offset to -1 and then increase the border with by 1 to get a solid active window border color underneath the whole border edge, without bleeding through to the background or similar, that otherwise looks like a gap. This leaves what has the look and feel of a single pixel border in many scenarios except as follows.

As an example the Epic launcher uses a different DWM window style, that adjusts the border behavior. The border there is completely opaque and spills over a single pixel border window, effectively making the active border window invisible. For users trying to do that single pixel border style, it will effectively disappear under those windows. The correct fix for this is to interrogate the DWM border style of the windows we are decorating and adjust for this. As it stands right now I doubt any users are affected by this, as if they're arranging for single pixel borders today, they will be missing borders on many applications that have incorrect sizing and offsetting.

One final thing that is also worth considering for a near future, aside from detecting DWM styles for border edges, is to also use that to apply a small fixup on the window corner radius for those applications. Relatedly, we could also offer a general border radius option, and a really polished fix would work on addressing DWM properties that observe the default Windows 11 corner styles, where the bottom right "resizable border" has a non-cicular inset on the corner curve - we could fill that in, or conform to it (the latter requires doing some more fancy drawing).

🔄 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/678 **Author:** [@raggi](https://github.com/raggi) **Created:** 2/20/2024 **Status:** ✅ Merged **Merged:** 2/26/2024 **Merged by:** [@LGUG2Z](https://github.com/LGUG2Z) **Base:** `master` ← **Head:** `raggi/borders` --- ### 📝 Commits (9) - [`ba52f1a`](https://github.com/LGUG2Z/komorebi/commit/ba52f1a87caf6bb67af898a74c658b93409e3bef) komorebi{,-core}: use window bounds without shadow - [`3b8bc0c`](https://github.com/LGUG2Z/komorebi/commit/3b8bc0ce8317c06d877763a794f70c9f19e8b662) fix(cfg,komorebi): remove all uses of invisible borders - [`9d07938`](https://github.com/LGUG2Z/komorebi/commit/9d07938b968ac32483cffdf7f12e1d64dbd44aff) fix(komorebi): restore borders, no more DWM border on border window - [`c87cf61`](https://github.com/LGUG2Z/komorebi/commit/c87cf610e12b90cfd01333249cd5adf4b49a42f0) fix(komorebi): account for border offset and width in layout - [`1469d0f`](https://github.com/LGUG2Z/komorebi/commit/1469d0f1b327cc10b6d264ed36fb5dc160c5b2ac) fix(komorebi): account for border decorations on resize - [`ad4a899`](https://github.com/LGUG2Z/komorebi/commit/ad4a89917a7ae9ba97fdb45d308886bd992c6881) fix(config): set new default border offset and width - [`6b24827`](https://github.com/LGUG2Z/komorebi/commit/6b2482701e8e9ad845488f218315496466e34b19) fix(komorebi): raise windows and border to top, not topmost - [`6e95084`](https://github.com/LGUG2Z/komorebi/commit/6e95084b9155cc279bdad12a8e6390e8f42249a0) fix(komorebi): close the corner gap around rounded corners - [`dc88ea4`](https://github.com/LGUG2Z/komorebi/commit/dc88ea4ec810a3a3bd2c2083c2481ad336d45407) fix(komorebi): don't raise the border window to top ### 📊 Changes **14 files changed** (+163 additions, -229 deletions) <details> <summary>View changed files</summary> 📝 `komorebi-core/src/arrangement.rs` (+2 -2) 📝 `komorebi-core/src/rect.rs` (+24 -7) 📝 `komorebi/src/border.rs` (+4 -44) 📝 `komorebi/src/lib.rs` (+1 -2) 📝 `komorebi/src/monitor.rs` (+1 -2) 📝 `komorebi/src/process_command.rs` (+6 -23) 📝 `komorebi/src/process_event.rs` (+5 -20) 📝 `komorebi/src/static_config.rs` (+4 -42) 📝 `komorebi/src/window.rs` (+2 -29) 📝 `komorebi/src/window_manager.rs` (+14 -38) 📝 `komorebi/src/windows_api.rs` (+62 -11) 📝 `komorebi/src/windows_callbacks.rs` (+15 -2) 📝 `komorebi/src/workspace.rs` (+21 -5) 📝 `schema.json` (+2 -2) </details> ### 📄 Description This includes three changes that could be included independently though each has some side effect that is adjusted by the latter to better align with the overall goal. I set out to remove the inconsistent gap and miscoloration around windows. This was originating in the interactions with DWM decorations. First the API that we're using to read window size is shifted to one that returns Window dimensions without including the DWM/theme decorations. Next in order to fix a number of new regressions vs. the application database, we needed to remove the use of the invisible borders - these were a side effect of the DWM decorations. They're no longer needed, as application Window dimensions are now correct, with one notable interaction with theming (below). Finally we move away from allowing/using DWM decorations on the border window. While this was giving us a rounded corner, it was causing offset bugs due to the fact that the theme is not symmetrical. This was making it impossible to draw very thin borders correctly, for example few pixel borders. There is one final caveat noted here, the problem exists already in a different form, but for the same as yet unresolved reasons. Single pixel borders work correctly with this setup but there remain overlapping concerns with the system them. The windows DWM theme adds an active window border as well, and how opaque this border is depends upon the theme (this is present even if the drop shadow is off). That border often produces what appears to be a single semi-transparent pixel border around the window that looks like a "gap" in many scenarios. Most users will want to set border-offset to -1 and then increase the border with by 1 to get a solid active window border color underneath the whole border edge, without bleeding through to the background or similar, that otherwise looks like a gap. This leaves what has the look and feel of a single pixel border in many scenarios except as follows. As an example the Epic launcher uses a different DWM window style, that adjusts the border behavior. The border there is completely opaque and spills over a single pixel border window, effectively making the active border window invisible. For users trying to do that single pixel border style, it will effectively disappear under those windows. The correct fix for this is to interrogate the DWM border style of the windows we are decorating and adjust for this. As it stands right now I doubt any users are affected by this, as if they're arranging for single pixel borders today, they will be missing borders on many applications that have incorrect sizing and offsetting. One final thing that is also worth considering for a near future, aside from detecting DWM styles for border edges, is to also use that to apply a small fixup on the window corner radius for those applications. Relatedly, we could also offer a general border radius option, and a really polished fix would work on addressing DWM properties that observe the default Windows 11 corner styles, where the bottom right "resizable border" has a non-cicular inset on the corner curve - we could fill that in, or conform to it (the latter requires doing some more fancy drawing). --- <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:53:55 +01:00
adam closed this issue 2026-01-05 14:53:55 +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#1051
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?