feat(wm): cloak off-screen scrolling containers for multi-monitors#1675
Draft
CtByte wants to merge 1 commit intoLGUG2Z:masterfrom
Draft
feat(wm): cloak off-screen scrolling containers for multi-monitors#1675CtByte wants to merge 1 commit intoLGUG2Z:masterfrom
CtByte wants to merge 1 commit intoLGUG2Z:masterfrom
Conversation
…port The scrolling layout positions all containers in a horizontal strip, where only a window of N visible columns is on-screen at any time. Containers outside this visible window are placed at coordinates beyond the workspace boundaries. On a single monitor this works fine — those coordinates fall into empty virtual space and the windows are effectively invisible. On multi-monitor setups, however, those off-screen coordinates land on neighbouring monitors, causing containers to appear where they shouldn't. Because of this, the scrolling layout was restricted to single-monitor configurations. This change removes that restriction by cloaking containers that fall outside the visible workspace area. Each update cycle, every container's layout rect is checked for horizontal overlap with the workspace bounds. Containers outside the visible region are cloaked via the existing undocumented SetCloak COM interface and their Win32 positioning calls are skipped entirely. Containers that scroll back into view are uncloaked and positioned normally. A dedicated scrolling_cloaked_hwnds set on the workspace tracks which windows are currently cloaked for scrolling purposes, kept separate from the HIDDEN_HWNDS mechanism used for workspace switching to avoid interference between the two. Several edge cases are handled: when restoring a workspace, off-screen containers are not uncloaked to prevent a brief flash on neighbouring monitors before the layout update runs. When a window is removed from a scrolling workspace while cloaked, it is uncloaked before removal so it remains visible when managed elsewhere. When the layout changes away from scrolling or monocle is toggled on, all scrolling-cloaked windows are uncloaked. If a user Alt-Tabs to a cloaked container, the uncloak event is intercepted and the layout scrolls to reveal that container rather than following the normal reconciliation path.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Screen.Recording.2026-03-11.091739.mp4
The scrolling layout positions all containers in a horizontal strip, where only a window of N visible columns is on-screen at any time. Containers outside this visible window are placed at coordinates beyond the workspace boundaries. On a single monitor this works fine — those coordinates fall into empty virtual space and the windows are effectively invisible. On multi-monitor setups, however, those off-screen coordinates land on neighbouring monitors, causing containers to appear where they shouldn't. Because of this, the scrolling layout was restricted to single-monitor configurations.
This change removes that restriction by cloaking containers that fall outside the visible workspace area. Each update cycle, every container's layout rect is checked for horizontal overlap with the workspace bounds. Containers outside the visible region are cloaked via the existing undocumented SetCloak COM interface and their Win32 positioning calls are skipped entirely. Containers that scroll back into view are uncloaked and positioned normally. A dedicated scrolling_cloaked_hwnds set on the workspace tracks which windows are currently cloaked for scrolling purposes, kept separate from the HIDDEN_HWNDS mechanism used for workspace switching to avoid interference between the two.
Several edge cases are handled: when restoring a workspace, off-screen containers are not uncloaked to prevent a brief flash on neighbouring monitors before the layout update runs. When a window is removed from a scrolling workspace while cloaked, it is uncloaked before removal so it remains visible when managed elsewhere. When the layout changes away from scrolling or monocle is toggled on, all scrolling-cloaked windows are uncloaked. If a user Alt-Tabs to a cloaked container, the uncloak event is intercepted and the layout scrolls to reveal that container rather than following the normal reconciliation path.