mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
[FEAT]: Remember a window's workspace and monitor when the monitor configuration is changed #466
Reference in New Issue
Block a user
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?
Originally created by @edgimar on GitHub (Sep 6, 2024).
I'm not sure if this is a feature or a bug, but I would expect Komorebi to keep track of the (monitor, workspace) pair that each window is assigned to (possibly in a way that persists across restarts of Komorebi). Then when a monitor reconfiguration occurs, Komorebi should ensure that each window that matches the last known (monitor, workspace, window) tuple is moved to the correct monitor and workspace.
As it is, I need to restart Komorebi and manually place windows every time I undock and re-dock my laptop (the dock adds two additional monitors). This is also the case when I hibernate and resume, if I have switched to a different dock (also having two slightly different monitors).
If detecting such monitor changes is not possible to do automatically, it would still be helpful to have a command to manually move all windows to the last known (monitor, workspace) associated with them.
Perhaps one complication is how to keep track of these associations when the number of monitors decreases. A model like the following might make sense here: each workspace (and its windows) is associated with a monitor, and when that monitor goes away, the workspace is moved to one of the remaining monitors. When the monitor becomes available again, then the workspace can be moved back to that monitor (so you'd need to keep track of what monitor the workspace was previously on -- some kind of stack?).
@alex-ds13 commented on GitHub (Feb 26, 2025):
@edgimar Can you test the latest master version and see if it fixes this issue for you?
@edgimar commented on GitHub (Mar 7, 2025):
With that version, windows return to the monitors they were on after the monitors are reconnected, but this does not restore the workspace that they were on (so all the windows show up on the same workspace for a particular monitor).
@alex-ds13 commented on GitHub (Mar 8, 2025):
On the Windows
Settings -> System -> Display, onMultiple Displaysdisable theRemember window locations based on monitor connection.@Thomas-Schmall commented on GitHub (Jun 17, 2025):
I'm unsure if it's the same issue... but as a beginner I'm completely confused by the way windows change their spots on the monitors and workspaces. On other window managers it felt quite consistent: I declare which window should start where, or I assign them on the go... and then they stay there. Or pop back up there if I go back (or go fullscreen for a moment).
With komorebi the location changes constantly. And sometimes they switch workspaces if I focus them from the win-10 taskbar.
Defining the rules in the komorebi.json seems very tricky - I can't find explanations or examples. Just (non-programmer) unreadable schema definitions.
The idea that komorebi could remember workspace assignments between sessions sounds very handy.
I suppose this belongs here. Either way, just wanted to bring up that there is an issue - either a bug or unexpected design.