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

[BUG]: Monitor indexes are not stable #151

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

Originally created by @maxbane on GitHub (Oct 24, 2022).

Describe the bug
My physical display layout is as shown below (from Windows Display Settings):

image

I want the portrait-oriented monitor to use the "rows" layout algorithm, and everything else to use "bsp". So, as a first-time user, I did some experimenting with komorebic query focused-monitor-index to determine what Komorebi's index was for each monitor, and wrote my config like so:

; laptop monitor (leftmost monitor)
WorkspaceLayout(0, 0, "bsp")
; Portrait monitor
WorkspaceLayout(1, 0, "rows")
; Upper monitor
WorkspaceLayout(2, 0, "bsp")
; Lower monitor
WorkspaceLayout(3, 0, "bsp")

However, this has been unstable. After turning monitors off/on, or disconnecting the laptop from its dock and reconnecting, or sometimes even after simply restarting the computer, I find that the portrait monitor now has "bsp" layout and one of the other monitors (apparently random) has "rows" layout. When this happens, komorebic query focused-monitor-index indeed confirms that the indexes have all gotten scrambled. I can fix it temporarily by editing my config to use the new indexes, but inevitably they eventually get scrambled again.

Note that even though the indexes get scrambled, Komorebi seems to retain correct awareness of the spatial relationships between monitors, i.e., moving windows up/down/left/right across monitor boundaries still functions correctly and as expected.

To Reproduce
See above.

Expected behavior
There should be some kind of stable way to refer to monitors when using configuration commands. Some ideas:

  • Windows Display Settings always shows the same label for the same monitor (i.e. the numbers in the screenshot above), so Windows at least does have some kind of stable indexing. Could Komorebi just use the same numeric labels that Windows Display Settings does?
  • What about UUIDs? Instead of indexes, komorebi's configuration commands could accept monitor UUIDs, and the query command could be used to retrieve the UUIDs that Komorebi is using.

Operating System

OS Name:                   Microsoft Windows 10 Pro
OS Version:                10.0.19044 N/A Build 19044
Originally created by @maxbane on GitHub (Oct 24, 2022). **Describe the bug** My physical display layout is as shown below (from Windows Display Settings): ![image](https://user-images.githubusercontent.com/792504/197554694-7f3a4ea4-d9cf-449e-a63c-3a1df2434841.png) I want the portrait-oriented monitor to use the "rows" layout algorithm, and everything else to use "bsp". So, as a first-time user, I did some experimenting with `komorebic query focused-monitor-index` to determine what Komorebi's index was for each monitor, and wrote my config like so: ``` ; laptop monitor (leftmost monitor) WorkspaceLayout(0, 0, "bsp") ; Portrait monitor WorkspaceLayout(1, 0, "rows") ; Upper monitor WorkspaceLayout(2, 0, "bsp") ; Lower monitor WorkspaceLayout(3, 0, "bsp") ``` However, this has been unstable. After turning monitors off/on, or disconnecting the laptop from its dock and reconnecting, or sometimes even after simply restarting the computer, I find that the portrait monitor now has "bsp" layout and one of the other monitors (apparently random) has "rows" layout. When this happens, `komorebic query focused-monitor-index` indeed confirms that the indexes have all gotten scrambled. I can fix it temporarily by editing my config to use the new indexes, but inevitably they eventually get scrambled again. Note that even though the indexes get scrambled, Komorebi seems to retain correct awareness of the spatial relationships between monitors, i.e., moving windows up/down/left/right across monitor boundaries still functions correctly and as expected. **To Reproduce** See above. **Expected behavior** There should be some kind of stable way to refer to monitors when using configuration commands. Some ideas: - Windows Display Settings always shows the same label for the same monitor (i.e. the numbers in the screenshot above), so Windows at least does have some kind of stable indexing. Could Komorebi just use the same numeric labels that Windows Display Settings does? - What about UUIDs? Instead of indexes, komorebi's configuration commands could accept monitor UUIDs, and the `query` command could be used to retrieve the UUIDs that Komorebi is using. **Operating System** ``` OS Name: Microsoft Windows 10 Pro OS Version: 10.0.19044 N/A Build 19044 ```
adam added the bug label 2026-01-05 14:48:35 +01:00
adam closed this issue 2026-01-05 14:48:35 +01:00
adam commented 2026-01-05 14:48:35 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Oct 25, 2022):

99389f40f9

If this ^ goes anywhere I think I should be able to add a command to target monitors by name as well as by index.

@LGUG2Z commented on GitHub (Oct 25, 2022): https://github.com/LGUG2Z/komorebi/commit/99389f40f9bd927b16dae6b0e9a1088804e86a95 If this ^ goes anywhere I think I should be able to add a command to target monitors by name as well as by index.
adam commented 2026-01-05 14:48:35 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Oct 26, 2022):

On second thought that also wouldn't work as the monitor names are also not stable, but continuously incrementing on reconnection.

However, what should always be stable once the display positionings have been set is the size, which is a RECT that identifies the dimensions of the display on the big layout canvas in the settings.

      {
        "id": 52756727,
        "name": "DISPLAY22",
        "size": {
          "left": 808,
          "top": 2160,
          "right": 1916,
          "bottom": 1332
        },
    // ...
    }

I think it should be possible to set an index preference for each display RECT, so that on reconnection, instead of being pushed to the back of the Ring<Monitor>, it can be inserted at the desired index if either that index is not out of bounds, or if expanding the vector to accommodate that index would not insert an empty element in order to bring that desired index into bounds.

@LGUG2Z commented on GitHub (Oct 26, 2022): On second thought that also wouldn't work as the monitor names are also not stable, but continuously incrementing on reconnection. However, what _should_ always be stable once the display positionings have been set is the `size`, which is a `RECT` that identifies the dimensions of the display on the big layout canvas in the settings. ```json5 { "id": 52756727, "name": "DISPLAY22", "size": { "left": 808, "top": 2160, "right": 1916, "bottom": 1332 }, // ... } ``` I think it should be possible to set an index preference for each display `RECT`, so that on reconnection, instead of being pushed to the back of the `Ring<Monitor>`, it can be inserted at the desired index if either that index is not out of bounds, or if expanding the vector to accommodate that index would not insert an empty element in order to bring that desired index into bounds.
adam commented 2026-01-05 14:48:36 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Oct 27, 2022):

Set the monitor index preference for a monitor identified using its size

Usage: komorebic.exe monitor-index-preference <INDEX_PREFERENCE> <LEFT> <TOP> <RIGHT> <BOTTOM>

Arguments:
  <INDEX_PREFERENCE>  Preferred monitor index (zero-indexed)
  <LEFT>              Left value of the monitor's size Rect
  <TOP>               Top value of the monitor's size Rect
  <RIGHT>             Right value of the monitor's size Rect
  <BOTTOM>            Bottom value of the monitor's size Rect

This command has been added on the above referenced commit and from my limited testing with my iPad as an additional display it seems to keep monitor indices stable across connections and disconnections.

@LGUG2Z commented on GitHub (Oct 27, 2022): ``` Set the monitor index preference for a monitor identified using its size Usage: komorebic.exe monitor-index-preference <INDEX_PREFERENCE> <LEFT> <TOP> <RIGHT> <BOTTOM> Arguments: <INDEX_PREFERENCE> Preferred monitor index (zero-indexed) <LEFT> Left value of the monitor's size Rect <TOP> Top value of the monitor's size Rect <RIGHT> Right value of the monitor's size Rect <BOTTOM> Bottom value of the monitor's size Rect ``` This command has been added on the above referenced commit and from my limited testing with my iPad as an additional display it seems to keep monitor indices stable across connections and disconnections.
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#151
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?