You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
@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.
Summary
If we monocle a stack container we won't be able to use the
cycle-stack
orfocus-stack-window
commands since those try to operate on theself.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)
The text was updated successfully, but these errors were encountered: