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 #752] [CLOSED] komorebi: correct use of z-order flags #1083

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

📋 Pull Request Information

Original PR: https://github.com/LGUG2Z/komorebi/pull/752
Author: @raggi
Created: 4/13/2024
Status: ❌ Closed

Base: master ← Head: raggi/no-topmost

📝 Commits (2)

  • 35c5d76 komorebi: remove mutability from window and events
  • 52e22de komorebi: correct use of z-order flags

📊 Changes

3 files changed (+36 additions, -24 deletions)

View changed files

📝 komorebi/src/process_event.rs (+12 -17)
📝 komorebi/src/window.rs (+2 -2)
📝 komorebi/src/windows_api.rs (+22 -5)

📄 Description

We had been setting managed windows to HWND_TOPMOST which is a sticky and viral parameter. This was also the cause of the border window ending up behind other windows in an undesirable fashion, as even though it was marked WS_EX_TOPMOST, we were then having to mark it HWND_NOTOPTMOST when raising it to avoid it ending up drawing over other windows.

Since we've fixed the border window to no longer be visible when unmanaged windows are focused, we can now set the border window to HWND_TOP when we reposition, which will ensure it's drawing in the order that we want.

Now we also set managed windows only to HWND_TOP, rather than HWND_TOPMOST which stops us from incorrectly reordering internal concerns vs. child windows and owned windows that we're not managing. Windows are still brought to the foreground as expected/desired, but they're no longer 'sticking' there, nor are they drawing over the border window.

This change does have a slight transition behavior as it initially rolls out, as prior versions of the Komorebi have been setting HWND_TOPMOST, which as a sticky parameter won't be cleared until the application or host system removes that flag. This means that the final z-order behavior will come good eventually. To immediately see the correct results, restarting affected apps or logging out / in will do. Unfortuantely we can't just set HWND_NOTTOPMOST, as similarly to setting HWND_TOPMOST, this can cause issues with an applications intended owned-window Z-Ordering - mostly affecting toolwindows and child windows, such as file dialogs, toolbars and so on, most of which we do not manage.

🔄 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/752 **Author:** [@raggi](https://github.com/raggi) **Created:** 4/13/2024 **Status:** ❌ Closed **Base:** `master` ← **Head:** `raggi/no-topmost` --- ### 📝 Commits (2) - [`35c5d76`](https://github.com/LGUG2Z/komorebi/commit/35c5d765d66d679494a81293521066522006f7eb) komorebi: remove mutability from window and events - [`52e22de`](https://github.com/LGUG2Z/komorebi/commit/52e22de348581c531feb205f9703162e9e64b831) komorebi: correct use of z-order flags ### 📊 Changes **3 files changed** (+36 additions, -24 deletions) <details> <summary>View changed files</summary> 📝 `komorebi/src/process_event.rs` (+12 -17) 📝 `komorebi/src/window.rs` (+2 -2) 📝 `komorebi/src/windows_api.rs` (+22 -5) </details> ### 📄 Description We had been setting managed windows to HWND_TOPMOST which is a sticky and viral parameter. This was also the cause of the border window ending up behind other windows in an undesirable fashion, as even though it was marked WS_EX_TOPMOST, we were then having to mark it HWND_NOTOPTMOST when raising it to avoid it ending up drawing over other windows. Since we've fixed the border window to no longer be visible when unmanaged windows are focused, we can now set the border window to HWND_TOP when we reposition, which will ensure it's drawing in the order that we want. Now we also set managed windows only to HWND_TOP, rather than HWND_TOPMOST which stops us from incorrectly reordering internal concerns vs. child windows and owned windows that we're not managing. Windows are still brought to the foreground as expected/desired, but they're no longer 'sticking' there, nor are they drawing over the border window. This change does have a slight transition behavior as it initially rolls out, as prior versions of the Komorebi have been setting HWND_TOPMOST, which as a sticky parameter won't be cleared until the application or host system removes that flag. This means that the final z-order behavior will come good eventually. To immediately see the correct results, restarting affected apps or logging out / in will do. Unfortuantely we can't just set HWND_NOTTOPMOST, as similarly to setting HWND_TOPMOST, this can cause issues with an applications intended owned-window Z-Ordering - mostly affecting toolwindows and child windows, such as file dialogs, toolbars and so on, most of which we do not manage. --- <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:02 +01:00
adam closed this issue 2026-01-05 14:54:02 +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#1083
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?