[BUG]: Can't cycle stack windows if stack is monocled #502

New Issue

2026-01-05T14:51:09+01:00

adam commented

2026-01-05 14:51:09 +01:00

Originally created by @alex-ds13 on GitHub (Oct 21, 2024).

Summary

If we monocle a stack container we won't be able to use the cycle-stack or focus-stack-window commands since those try to operate on the self.focused_container of the window manager which when monocled is incorrect, since it only looks on the workspace containers ignoring the monocle container.

Version Information

0.1.29+

Komorebi Configuration

(not needed)

Hotkey Configuration

(not needed)

Output of komorebic check

(not needed)

Originally created by @alex-ds13 on GitHub (Oct 21, 2024). ### Summary If we monocle a stack container we won't be able to use the `cycle-stack` or `focus-stack-window` commands since those try to operate on the `self.focused_container` of the window manager which when monocled is incorrect, since it only looks on the workspace containers ignoring the monocle container. ### Version Information 0.1.29+ ### Komorebi Configuration ```json (not needed) ``` ### Hotkey Configuration (not needed) ### Output of komorebic check (not needed)

adam added the bug label 2026-01-05 14:51:09 +01:00

adam closed this issue

2026-01-05 14:51:09 +01:00

adam commented

2026-01-05 14:51:10 +01:00

@alex-ds13 commented on GitHub (Oct 21, 2024):

@LGUG2Z Feel free to assign this one to me as well.

I will fix this one by adding a check for monocle containers first.

However I feel that a bunch of this issues would be non-existent if instead of removing the containers from the workspace containers ring to move that container to the monocle, we kept the containers always on the ring and simply set the container id to the monocle. Same thing for floating_windows they could still have their container on the ring and then the floating_windows would be a vec of ids. This way the focused container could always be get easily from the ring. And even floating windows could be focused meaning that when changing workspaces if that floating window was focused we would be able to set it to focused again. But this is a discussion for another time.

@alex-ds13 commented on GitHub (Oct 21, 2024): @LGUG2Z Feel free to assign this one to me as well. I will fix this one by adding a check for monocle containers first. However I feel that a bunch of this issues would be non-existent if instead of removing the containers from the workspace `containers` ring to move that container to the monocle, we kept the containers always on the ring and simply set the container id to the monocle. Same thing for `floating_windows` they could still have their container on the ring and then the `floating_windows` would be a vec of ids. This way the focused container could always be get easily from the ring. And even floating windows could be focused meaning that when changing workspaces if that floating window was focused we would be able to set it to focused again. But this is a discussion for another time.

adam referenced this issue

2026-01-05 14:53:33 +01:00

[PR #502] [CLOSED] chore(deps): bump sysinfo from 0.29.4 to 0.29.6 #957

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/komorebi#502