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

Multi monitor layouts is broken partially #62

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

Originally created by @pigmej on GitHub (Nov 22, 2021).

Originally assigned to: @LGUG2Z on GitHub.

I have a feeling that in recent versions the multi monitor setup got a bit broken. I have a feeling that now sometimes layouts are confused and sometimes window appears on wrong monitor etc.

Were there any changes in the code that would touch that logic?

Originally created by @pigmej on GitHub (Nov 22, 2021). Originally assigned to: @LGUG2Z on GitHub. I have a feeling that in recent versions the multi monitor setup got a bit broken. I have a feeling that now sometimes layouts are confused and sometimes window appears on wrong monitor etc. Were there any changes in the code that would touch that logic?
adam added the bug label 2026-01-05 14:48:00 +01:00
adam closed this issue 2026-01-05 14:48:00 +01:00
adam commented 2026-01-05 14:48:01 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Nov 22, 2021):

Can you describe the behaviours your are seeing in a little more detail and share the commit that you are currently running from?

This is the only commit that I can think of that might have resulted in unexpected regressions when laying out windows across multiple monitors: f9785bef55

@LGUG2Z commented on GitHub (Nov 22, 2021): Can you describe the behaviours your are seeing in a little more detail and share the commit that you are currently running from? This is the only commit that I can think of that might have resulted in unexpected regressions when laying out windows across multiple monitors: https://github.com/LGUG2Z/komorebi/commit/f9785bef558202c42772fef99b9944c342522716
adam commented 2026-01-05 14:48:01 +01:00
Author
Owner
Copy Link

@pigmej commented on GitHub (Nov 23, 2021):

@LGUG2Z hash is f9785bef558202c42772fef99b9944c342522716 which is current master.

The behavior that I see seems to vary slightly but mainly window sometimes appear on the other screen just when switching workspaces, and then the layout on the other screen is broken in a way that there is empty space etc.

Looks like komorebi is confused where the window should be and puts it on correct workspace but wrong physical screen.

I'm trying to find a case when it happens that one could reproduce , that's why I asked if there were some changes in the logic that would explain that.

@pigmej commented on GitHub (Nov 23, 2021): @LGUG2Z hash is `f9785bef558202c42772fef99b9944c342522716` which is current master. The behavior that I see seems to vary slightly but mainly window sometimes appear on the other screen just when switching workspaces, and then the layout on the other screen is broken in a way that there is empty space etc. Looks like komorebi is confused where the window should be and puts it on correct workspace but wrong physical screen. I'm trying to find a case when it happens that one could reproduce , that's why I asked if there were some changes in the logic that would explain that.
adam commented 2026-01-05 14:48:01 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Nov 23, 2021):

There have been 34 commits since the 0.1.6 release, looking through the list I think that the following commits could have reasonably introduced the sort of regression that you are describing:

d3cb9e07f7
7fd545ca35
4a19edaab2

If we can narrow down the commit range that the regression may have been introduced in it should make it easier to figure out what has happened. Can you try to reproduce the same behaviour on 0.1.6 and the three commit hashes listed above when you get a moment?

@LGUG2Z commented on GitHub (Nov 23, 2021): There have been [34 commits since the 0.1.6 release](https://github.com/LGUG2Z/komorebi/compare/v0.1.6...master), looking through the list I think that the following commits could have reasonably introduced the sort of regression that you are describing: https://github.com/LGUG2Z/komorebi/commit/d3cb9e07f7fc0a7b03774c90b2c6bdba5920a836 https://github.com/LGUG2Z/komorebi/commit/7fd545ca35e75788f9c8d995157b38786b7377d0 https://github.com/LGUG2Z/komorebi/commit/4a19edaab2bef63043ba14a3a1cd6b9820e580af If we can narrow down the commit range that the regression may have been introduced in it should make it easier to figure out what has happened. Can you try to reproduce the same behaviour on 0.1.6 and the three commit hashes listed above when you get a moment?
adam commented 2026-01-05 14:48:01 +01:00
Author
Owner
Copy Link

@pigmej commented on GitHub (Nov 23, 2021):

Hey,

I will try to replicate that and bissect it somehow.

@pigmej commented on GitHub (Nov 23, 2021): Hey, I will try to replicate that and bissect it somehow.
adam commented 2026-01-05 14:48:01 +01:00
Author
Owner
Copy Link

@pigmej commented on GitHub (Dec 6, 2021):

I cannot replicate it easily anymore.

Eighter that was some one-off issue or idk. one suspicion would be that something got broken in the state while doing upgrades of komorebi (?)

I think we shall close that issue and wait till I'll be able to replicate it again.

@pigmej commented on GitHub (Dec 6, 2021): I cannot replicate it easily anymore. Eighter that was some one-off issue or idk. one suspicion would be that something got broken in the state while doing upgrades of komorebi (?) I think we shall close that issue and wait till I'll be able to replicate it again.
adam commented 2026-01-05 14:48:01 +01:00
Author
Owner
Copy Link

@pigmej commented on GitHub (Dec 16, 2021):

@LGUG2Z I think I found the issue. If you switch workspaces a few times fast enough then komorebi will get confused. That's especially visible with the new "minimize" method.

Basically what happens is, komorebi state mismatches the actual windows state (wrong workspaces for certain windows etc), same happens if you send a window to monitor a few times fast enough.

@pigmej commented on GitHub (Dec 16, 2021): @LGUG2Z I think I found the issue. If you switch workspaces a few times fast enough then komorebi will get confused. That's especially visible with the new "minimize" method. Basically what happens is, komorebi state mismatches the actual windows state (wrong workspaces for certain windows etc), same happens if you send a window to monitor a few times fast enough.
adam commented 2026-01-05 14:48:01 +01:00
Author
Owner
Copy Link

@JSamir commented on GitHub (Dec 25, 2021):

I also observe this, buth with the latest released version.

What is the best way to gather data for you to analyze this? I've also got some issues where at some point "nothing" works correctly anymore and I need to restart komorebic. So I would like to gather data for such a case and open an issue here.

@JSamir commented on GitHub (Dec 25, 2021): I also observe this, buth with the latest released version. What is the best way to gather data for you to analyze this? I've also got some issues where at some point "nothing" works correctly anymore and I need to restart komorebic. So I would like to gather data for such a case and open an issue here.
adam commented 2026-01-05 14:48:01 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Jan 13, 2022):

komorebi listens on two separate threads to incoming commands from komorebic and a subset of WinEvents and tries to reconcile a state based on data streams. The order of events coming through the komorebic data stream is predictable and knowable since it is based on user input, but the WinEvent data stream is a bit of a black box for me because it's whatever the systems surfaces when PeekMessageW is called in the MessageLoop.

The WindowManager object is wrapped in a Mutex to protect the state from simultaneous write access from both of those threads, significantly reducing the possibility of ending up with an invalid state.

Besides this, I'm not really sure how we can further enforce a valid internal window manager state, especially when executing multiple event-heavy operations repeatedly in a short timeframe (such as workspace switching).

Open to ideas on how to address this from people with more experience than I have working with the Windows API.

@LGUG2Z commented on GitHub (Jan 13, 2022): `komorebi` listens on two separate threads to incoming commands from `komorebic` and a [subset of WinEvents](https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/window_manager_event.rs#L108) and tries to reconcile a state based on data streams. The order of events coming through the `komorebic` data stream is predictable and knowable since it is based on user input, but the WinEvent data stream is a bit of a black box for me because it's whatever the systems surfaces when [PeekMessageW](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-peekmessagew) is [called in the MessageLoop](https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/winevent_listener.rs#L91). The WindowManager object is [wrapped in a Mutex](https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/main.rs#L364) to protect the state from simultaneous write access from both of those threads, significantly reducing the possibility of ending up with an invalid state. Besides this, I'm not really sure how we can further enforce a valid internal window manager state, especially when executing multiple event-heavy operations repeatedly in a short timeframe (such as workspace switching). Open to ideas on how to address this from people with more experience than I have working with the Windows API.
adam commented 2026-01-05 14:48:01 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Feb 12, 2023):

@pigmej @JSamir Check out this commit, just set window-hiding-behaviour to cloak: 80c98596dd

@LGUG2Z commented on GitHub (Feb 12, 2023): @pigmej @JSamir Check out this commit, just set `window-hiding-behaviour` to `cloak`: https://github.com/LGUG2Z/komorebi/commit/80c98596dd2cb4e28666e49c753ffc7e5137e09e
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#62
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?